From owner-aaa-wg@merit.edu Mon Apr 1 04:26:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07859 for ; Mon, 1 Apr 2002 04:26:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 434949122E; Mon, 1 Apr 2002 04:26:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 195ED9122F; Mon, 1 Apr 2002 04:26:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEE8B9122E for ; Mon, 1 Apr 2002 04:26:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE36E5DE2B; Mon, 1 Apr 2002 04:26:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 871C75DE1F for ; Mon, 1 Apr 2002 04:26:26 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ADF906A901; Mon, 1 Apr 2002 12:26:20 +0300 (EEST) Message-ID: <3CA81A10.1030608@kolumbus.fi> Date: Mon, 01 Apr 2002 11:28:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mccap@lucent.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Bug in Acct state machine Content-Type: multipart/mixed; boundary="------------000209080509050806010001" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------000209080509050806010001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pete, Bob, Thanks for taking a look at the state tables, and Pete I think you analysis was right on. I agree with the PendingI problem, and you suggested solution. I also agree with the split. Additionally, I think we should delete the accounting entries from the auth tables, and simply deal with accounting under 8.2 regardless of whether it is a part of an auth application or separate activity. Also, if we split the server and client on the accounting side, I think we can collapse all server side accounting states to Idle. And then to Bob's comments: > I think you might want to split the above "ASR Received" event > into three events, making the client's state machine more > consistent with the Server's state machine and with the base > protocol text; i.e. Yes. >Shouldn't the above be: > Discon ASR Received Send STA. Discon Not quite. The STA is sent by the server, not the client. There is an issue, however, on what to do if we have already sent an STR, are waiting for the STA to arrive but then we get an ASR from the server (STR and ASR meet on the wire). The -09 state machine simply ignored the ASR in this case, and on the server side was able to terminate the session if, while waiting for ASA would instead get STR. I think Pete's state machine gets it right as well. > > Open Authorization-Lifetime (and Cleanup Discon > > Auth-Grace-Period) expires > > on home server. > > I think going to Idle is more appropriate above, because the server > may not be receiving an STR from the client, i.e. > > Open Authorization-Lifetime (and Cleanup Idle > Auth-Grace-Period) expires > on home server. Yes, if the server didn't get an STR by this time, something is wrong. Idle is right I believe. > > Open Session-Timeout expires on Cleanup Discon > > home server > > I think going to Idle is more appropriate above, because the server > may not be receiving an STR from the client, i.e. > > Open Session-Timeout expires on Cleanup Idle > home server Yes, same here. > > Open STR Received Send STA Idle > > I'd add a "cleanup" to the above, i.e. > > Open STR Received Send STA, Idle > Cleanup Agreed. > I'd replace the above by: > > Not Open STR Received Send STA, Idle > Cleanup Yes, in theory the only remaining state beyond Discon is Idle and it can't have state, but it's good to make the state machine recover from errors. > Since the server isn't maintaining session state, I'd > delete the above "SERVER, STATELESS" table altogether. I think we should keep the table, but have it contain just one entry and state. > 1. When in the PendingX states, do you want to add entries for > an "Unsuccessful accounting answer received" event? I was trying to fight against this because of complexity it adds to the state machine. But I now see that Realtime-Required AVP has an effect to how these things should be treated, and hence I have now included even the error cases in the table. > 2. Do you want to add entries to deal with having to send a Stop > when a Start or Interim is still pending, e.g. something like: Yes. But given that a Start or Interim is already in progress, I don't want to send another message along at the same time. Therefore, I have put in 'Store Record' as an action. Ok? Updated state table attached, please review again! Jari --------------000209080509050806010001 Content-Type: text/plain; name="diamstates.txt" Content-Disposition: inline; filename="diamstates.txt" Content-Transfer-Encoding: 7bit 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service- Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN- SESSION-ID Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device Send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on Send STR Discon Access Device Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device Discon ASR Received None Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup Open Home server wants to Send ASR Open terminate the service Open ASA Received Cleanup Idle with Result-Code = UNKNOWN-SESSION-ID Open ASA Received None Open with Result-Code not = UNKNOWN-SESSION-ID Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Idle home server Open STR Received Send STA, Idle Cleanup Not ASA Received None No Change. Open Not STR Received Send STA, Idle Open Cleanup The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send serv. Idle request received, and specific successfully processed answer 8.2 Accounting Session State Machine For applications that only require accounting services or applications that have an accounting portion, the following state machines MUST be supported. The first is to be observed by clients, the second by servers. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send' means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. The event 'Failed answer' means that the Diameter client received a non-transient failure notification in the Accounting Answer command. Note that the action 'Disconnect user/dev' MUST have an effect also to the authorization session state table, e.g. cause the STR message to be sent, if the given application has both authentication/authorization and accounting portions. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests Send PendingS access accounting start req. Idle Client or device requests Send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE PendingS User service terminated Store PendingS stop record Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req. PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev not equal to GRANT_AND_LOSE PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available event record PendingE Failure to send and no buffer Idle space available PendingE Failed accounting event answer Idle received PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingB Failed accounting answer Delete Idle received record PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available stop record PendingL Failure to send and no buffer Idle space available PendingL Failed accounting stop answer Idle received SERVER, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Idle received, and successfully accounting processed. start answer Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Interim record received, Send Idle and successfully processed. accounting answer Idle Accounting stop request Send Idle received, and successfully accounting processed stop answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE --------------000209080509050806010001-- From owner-aaa-wg@merit.edu Mon Apr 1 09:05:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27605 for ; Mon, 1 Apr 2002 09:05:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AD8E91231; Mon, 1 Apr 2002 09:05:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FEAA91234; Mon, 1 Apr 2002 09:05:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9C8191231 for ; Mon, 1 Apr 2002 09:05:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B52945DD8C; Mon, 1 Apr 2002 09:05:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id CCCB35DE45 for ; Mon, 1 Apr 2002 09:05:13 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31E4Ou17140 for ; Mon, 1 Apr 2002 17:04:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 17:05:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 17:05:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Accounting-Realtime-Required Date: Mon, 1 Apr 2002 17:05:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E515@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Accounting-Realtime-Required Thread-Index: AcHW71LJrrND8Qf8T3uBZofbSZ18JQCgEBug From: To: , Cc: X-OriginalArrivalTime: 01 Apr 2002 14:05:12.0339 (UTC) FILETIME=[3D7AD630:01C1D986] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA27605 Hi all, Change made. John > ----- Original Message ----- > From: "Pete McCann" > To: > Sent: 29. maaliskuuta 2002 0:58 > Subject: [AAA-WG]: [issue] Accounting-Realtime-Required > > > > > > Issue: Accounting-Realtime-Required should appear > > in Section 9.7.2, and text in > Section 9.8.7 > > should give its AVP Code > > Submitter name: Pete McCann > > Submitter email address: mccap@lucent.com > > Date first submitted: 03-28-2002 > > Reference: > > Document: diameter-base-09 > > Comment type: Editorial > > Priority: 1 > > Section: 9.7.2, 9.8.7 > > > > Rationale: > > > > The Accounting-Realtime-Required AVP is defined in Section > 9.8.7, but > > is not mentioned in the ABNF for Accounting-Answer messages > in Section > > 9.7.2. Also, the description in Section 9.8.7 lists the AVP Code as > > "TBD", but the table on page 50-51 lists the AVP with Code 483. > > > > Requested Change: > > > > Add the following line to 9.7.2, > > after "[Accounting-Interim-Interval]": > > > > [ Accounting-Realtime-Required ] > > > > Change the first line of Section 9.8.7 to read: > > > > The Accounting-Realtime-Required AVP (AVP Code 483) is of type > > > > > > > > -Pete > > > From owner-aaa-wg@merit.edu Mon Apr 1 09:18:29 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28279 for ; Mon, 1 Apr 2002 09:18:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88E3791234; Mon, 1 Apr 2002 09:17:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54CC591236; Mon, 1 Apr 2002 09:17:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3845391234 for ; Mon, 1 Apr 2002 09:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 136745DDC0; Mon, 1 Apr 2002 09:17:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id CEAFA5DD91 for ; Mon, 1 Apr 2002 09:17:57 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A792E6A906 for ; Mon, 1 Apr 2002 17:17:56 +0300 (EEST) Message-ID: <3CA853B5.9050502@kolumbus.fi> Date: Mon, 01 Apr 2002 15:33:57 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Session-Server-Failover and STR References: <3CA81A10.1030608@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Jari Arkko Submitter email address: jari.arkko@kolumbus.fi Date first submitted: April 1, 2002 Reference: Document: Base Comment type: T Priority: S Section: 8.18 Rationale/Explanation of issue: The ALLOW_SERVICE and TRY_AGAIN_ALLOW_SERVICE cases talk about what to do after STR fails, and indicate that, if the delivery of the STR fails, the session should be terminated. Duh! Isn't the session terminated _anyway_ if we are in the progress of sending STRs? But perhaps I'm missing something. From owner-aaa-wg@merit.edu Mon Apr 1 09:18:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28312 for ; Mon, 1 Apr 2002 09:18:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65AA891236; Mon, 1 Apr 2002 09:18:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A15291238; Mon, 1 Apr 2002 09:18:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 321BA91236 for ; Mon, 1 Apr 2002 09:18:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8083F5DDC0; Mon, 1 Apr 2002 09:18:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 636FA5DD91 for ; Mon, 1 Apr 2002 09:18:00 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3519E6A901; Mon, 1 Apr 2002 17:17:55 +0300 (EEST) Message-ID: <3CA849CD.1040208@kolumbus.fi> Date: Mon, 01 Apr 2002 14:51:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mccap@lucent.com, aaa-wg@merit.edu Subject: [AAA-WG]: Re: Bug in Acct state machine References: <3CA81A10.1030608@kolumbus.fi> Content-Type: multipart/mixed; boundary="------------090409080200050207000507" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------090409080200050207000507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > >Shouldn't the above be: > > Discon ASR Received Send STA. Discon > > Not quite. The STA is sent by the server, not the client. > > There is an issue, however, on what to do if we have already sent an STR, > are waiting for the STA to arrive but then we get an ASR from the server > (STR and ASR meet on the wire). The -09 state machine simply ignored the > ASR in this case, and on the server side was able to terminate the session > if, while waiting for ASA would instead get STR. I think Pete's state > machine gets it right as well. On second thought, and on reading section 8.5, it seems that the more appropriate action is really answering the ASR also. The ASR could come from some other server than the one we sent the STR to. So, if we are in the progress of releasing the session already and we get ASR, we should respond with ASA Result-Code = Success. Modified state machine attached. Jari --------------090409080200050207000507 Content-Type: text/plain; name="diamstates.txt" Content-Disposition: inline; filename="diamstates.txt" Content-Transfer-Encoding: 7bit 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service- Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN- SESSION-ID Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device Send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on Send STR Discon Access Device Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device Discon ASR Received Send ASA Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup Open Home server wants to Send ASR Open terminate the service Open ASA Received Cleanup Idle with Result-Code = UNKNOWN-SESSION-ID Open ASA Received None Open with Result-Code not = UNKNOWN-SESSION-ID Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Idle home server Open STR Received Send STA, Idle Cleanup Not ASA Received None No Change. Open Not STR Received Send STA, Idle Open Cleanup The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send serv. Idle request received, and specific successfully processed answer 8.2 Accounting Session State Machine For applications that only require accounting services or applications that have an accounting portion, the following state machines MUST be supported. The first is to be observed by clients, the second by servers. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send' means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. The event 'Failed answer' means that the Diameter client received a non-transient failure notification in the Accounting Answer command. Note that the action 'Disconnect user/dev' MUST have an effect also to the authorization session state table, e.g. cause the STR message to be sent, if the given application has both authentication/authorization and accounting portions. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests Send PendingS access accounting start req. Idle Client or device requests Send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE PendingS User service terminated Store PendingS stop record Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req. PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev not equal to GRANT_AND_LOSE PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available event record PendingE Failure to send and no buffer Idle space available PendingE Failed accounting event answer Idle received PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingB Failed accounting answer Delete Idle received record PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available stop record PendingL Failure to send and no buffer Idle space available PendingL Failed accounting stop answer Idle received SERVER, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Idle received, and successfully accounting processed. start answer Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Interim record received, Send Idle and successfully processed. accounting answer Idle Accounting stop request Send Idle received, and successfully accounting processed stop answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE --------------090409080200050207000507-- From owner-aaa-wg@merit.edu Mon Apr 1 09:43:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29575 for ; Mon, 1 Apr 2002 09:43:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E46B91238; Mon, 1 Apr 2002 09:43:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC52791239; Mon, 1 Apr 2002 09:43:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5A0191238 for ; Mon, 1 Apr 2002 09:43:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E40E5DD91; Mon, 1 Apr 2002 09:43:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B6C8A5DD8D for ; Mon, 1 Apr 2002 09:43:17 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7E9326A901 for ; Mon, 1 Apr 2002 17:43:16 +0300 (EEST) Message-ID: <3CA86458.3050409@kolumbus.fi> Date: Mon, 01 Apr 2002 16:44:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 320: Base review results References: <3CA81A10.1030608@kolumbus.fi> <3CA853B5.9050502@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Over the weekend I went through the base-09 to try and catch both editorial and other possibly remaining problems. The results have been documented in the link http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#320 [ The file is still missing all comments beyond section 8.3 but I'm sure that it will be updated as soon as Bernard wakes up ;-) ] My comments are mostly editorial and/or improvements to explanations, but there are also a number of technical observations. For your convenience, I'll list the most interesting observations below. I didn't find anything horrible, the document seems to be in reasonable state even if there were a lot of smaller inconsistencies. We do need to have several people agree that the new state machines are OK, however. Jari ---- 1.2.1: - "If the new AVP value changes an existing command code's ABNF, the IANA AVP value request MUST include the new ABNF itself.": I'm not sure how a new AVP value for enumerated could ever change the ABNF. Propose to remove this sentence. 2.1: - "Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, in addition to interpreting ECONNREFUSED (a reset from the transport) and timed-out connection attempts." => "Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, subject to security policy on trusting such messages. Diameter implementations SHOULD also be able to interpret ECONNREFUSED (a reset from the transport) and timed-out connection attempts." 3.0: - Under Vendor-ID: "All vendor-specific Diameter commands require Information RFCs documenting the command.". First of all, it's Informational, not Information. Secondly, I really wonder about the usefulness of such a strong requirement. Section 11.2 talks about 'private use'. I would say "It is recommended that vendor-specific Diameter commands are documented in Informational RFCs." - The rules on DiameterIdentity contents are really unclear. I don't understand what the DI = fqdn statement intends to say, nor does it say anywhere how the multiple DIs on multi-server nodes are supposed to be created. I suggest the following text to replace this entry: "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection. The DiameterIdentity format is derived from the OctetString Base AVP Format. It uses the UTF-8 encoding and has the same requirements as UTF8String. The contents of the string MUST be the fqdn of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on." 4.4: - Under filterrule and the "assigned" explanation, the SHOULD remark about the first rule is confusing and incorrect for IPv6. Replace with the following text: "For IPv4, a typical first rule is often "deny in ip !assigned"" - Add after the "ipno/bits" text: "For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero." - Icmptypes, add text "Both the numeric values and the symbolic values listed below can be used." - Under QoSFilterRule, the dir, proto, and src/dst explanations are copy-pasted from the IPFilterrule, and somewhat incorrect (e.g. about the advice for the first rule). My suggestion is to include the following text *only*: dir The format is as described under IPFilterRule. proto The format is as described under IPFilterRule. src and dst The format is as described under IPFilterRule. - In QoSFilterRule, there's no similar statement as we had for IPFilterRule about what to do if the NAS doesn't support this filter. I propose the following: An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session. 4.5: - Remove all bnf starting from the "Fixed" since that has already been described earlier in the same way under the command abnf section. 5.1: - How come are the failover procedures *not* implemented if the primary goes to suspect list? This seems to be an error, given that the transport draft says FailOver is called from the OKAY state if timer fires. 5.6.4: - "Hanging octets are assumed to have value 0x80, but dimpled octets are ignored." What is this??!?!? 6.1.7: - The language is somewhat clear as to whether a single or multiple Redirect-Host AVPs are allowed. My suggestion is to allow multiple. Add the following text to the end of the section: "Multiple Redirect-Host AVPs are allowed. The receiver of the answer message with the 'E' bit set selects exactly one of these hosts as the destination of the redirected message." 6.10: - "Either the Auth-Application-Id or the Acct- Application-Id AVP MAY be present. Both AVPs MAY be present if they both contain the same value." This is somewhat problematic. Useful in CER, but not absolutely necessary. And would present problems in accounting or auth commands. My suggestion is to have CER include multiple copies if necessary. Therefore, propose the following text: "Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present." 8.1: - You've seen the state machine discussion on the list. This appears to be the only serious issue, and I hope everyone contributes in verifying that the latest version is really ok. - The auth state machines (both versions) have an action to send or receive an accounting message. This seems inadequate, and is perhaps a remnant of the old state machine which didn't do a good job in accounting. I propose that the two entries in the state machine are removed 9.1: - Add at the end of the second paragraph: "Note, however, that even if at the Diameter layer accounting requests are processed one by one, transport protocols used under Diameter typically batch several requests in the same packet under heavy traffic conditions. This may be sufficient for many applications." - "The server (or agents) uses the Accounting-Interim-Interval AVP to control the operation of the Diameter peer operating as a client." => "The server (or agents) uses the Accounting-Interim-Interval and Accounting-Realtime-Required AVPs to control the operation of the Diameter peer operating as a client." 9.2: - "A rejected Accounting-Request message SHOULD cause the user's session to be terminated." => "A rejected Accounting-Request message MAY cause the user's session to be terminated, depending on the value of the Accounting-Realtime-Required AVP received earlier for the session in question." 11: - Add a new section 11.16: 11.16 Accounting-Realtime-Required AVP Values As defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP Code 483) defines the values 1-3. All remaining values are available for assignment via IETF Consensus [IANA]. Jari From owner-aaa-wg@merit.edu Mon Apr 1 10:52:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02384 for ; Mon, 1 Apr 2002 10:52:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E91CD91208; Mon, 1 Apr 2002 10:52:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2F6F91239; Mon, 1 Apr 2002 10:52:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACC6891208 for ; Mon, 1 Apr 2002 10:52:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C4605DDB2; Mon, 1 Apr 2002 10:52:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1CD7F5DD8E for ; Mon, 1 Apr 2002 10:52:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g31F9Dn16016; Mon, 1 Apr 2002 07:09:13 -0800 Date: Mon, 1 Apr 2002 07:09:13 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Session-Server-Failover and STR In-Reply-To: <3CA853B5.9050502@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #323. On Mon, 1 Apr 2002, Jari Arkko wrote: > Submitter name: Jari Arkko > Submitter email address: jari.arkko@kolumbus.fi > Date first submitted: April 1, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 8.18 > Rationale/Explanation of issue: > > The ALLOW_SERVICE and TRY_AGAIN_ALLOW_SERVICE cases talk > about what to do after STR fails, and indicate that, if > the delivery of the STR fails, the session should be > terminated. > > Duh! Isn't the session terminated _anyway_ if we are > in the progress of sending STRs? > > But perhaps I'm missing something. > > From owner-aaa-wg@merit.edu Mon Apr 1 12:05:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05553 for ; Mon, 1 Apr 2002 12:05:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C13791237; Mon, 1 Apr 2002 12:04:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65FAE91239; Mon, 1 Apr 2002 12:04:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D3C391237 for ; Mon, 1 Apr 2002 12:04:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AD5A5DDC0; Mon, 1 Apr 2002 12:04:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id A81665DDB2 for ; Mon, 1 Apr 2002 12:04:48 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g31H4jE27829; Mon, 1 Apr 2002 12:04:45 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA05302; Mon, 1 Apr 2002 11:04:44 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g31H4iJ01098; Mon, 1 Apr 2002 11:04:44 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.37676.452855.623719@nwsgpc.ih.lucent.com> Date: Mon, 1 Apr 2002 11:04:44 -0600 (CST) From: Pete McCann To: Jari Arkko Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Bug in Acct state machine In-Reply-To: <3CA849CD.1040208@kolumbus.fi> References: <3CA81A10.1030608@kolumbus.fi> <3CA849CD.1040208@kolumbus.fi> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, it looks like there were some unresolved issues left in the state machine table. I'm glad I posted; it seems like separating client from server states made the issues stand out a little better. I think I agree with Jari's changes, but I have a question on something that I don't quite understand: Jari Arkko writes: > Open Home server wants to Send ASR Open > terminate the service > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID I think I agree that if an ASA is received in response to an ASR, and the code is DIAMETER_UNKNOWN_SESSION_ID, then we should clean up the session and go to idle. For instance, the access device may have forgotten about the session. Do we need something explicit to state that the ASA is in response to an ASR (i.e., the Identifiers match)? Note that the state on the left is just "Open", there is nothing to indicate we have sent an ASR. > Open ASA Received None Open > with Result-Code > not = UNKNOWN-SESSION-ID So the other two response codes are DIAMETER_SUCCESS and DIAMETER_UNABLE_TO_COMPLY. Should these both result in ignoring the response? I might agree with the latter, but certainly not the former! I suggest that DIAMETER_UNKNOWN_SESSION_ID and DIAMETER_SUCCESS be used for the first event, and that the second simply use DIAMETER_UNABLE_TO_COMPLY. -Pete From owner-aaa-wg@merit.edu Mon Apr 1 13:15:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08958 for ; Mon, 1 Apr 2002 13:15:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FEC791217; Mon, 1 Apr 2002 13:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21FBF91239; Mon, 1 Apr 2002 13:06:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0353191217 for ; Mon, 1 Apr 2002 13:05:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCA755DE44; Mon, 1 Apr 2002 13:05:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D50365DD8D for ; Mon, 1 Apr 2002 13:05:58 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CA0C86A901; Mon, 1 Apr 2002 21:05:56 +0300 (EEST) Message-ID: <3CA893D9.6030002@kolumbus.fi> Date: Mon, 01 Apr 2002 20:07:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete McCann Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Bug in Acct state machine References: <3CA81A10.1030608@kolumbus.fi> <3CA849CD.1040208@kolumbus.fi> <15528.37676.452855.623719@nwsgpc.ih.lucent.com> Content-Type: multipart/mixed; boundary="------------070006030406040708000703" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------070006030406040708000703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pete McCann wrote: > I'm glad I posted; it seems like separating client > from server states made the issues stand out a little better. Indeed. > > Open Home server wants to Send ASR Open > > terminate the service > > > Open ASA Received Cleanup Idle > > with Result-Code > > = UNKNOWN-SESSION-ID > > I think I agree that if an ASA is received in response to an ASR, and > the code is DIAMETER_UNKNOWN_SESSION_ID, then we should clean up the > session and go to idle. For instance, the access device may have > forgotten about the session. Do we need something explicit to state > that the ASA is in response to an ASR (i.e., the Identifiers match)? > Note that the state on the left is just "Open", there is nothing to > indicate we have sent an ASR. I'm not sure we do. The session-id match seems to be an implicit assumption on almost all events, just to get to the right session and its state we need session-id. > > > Open ASA Received None Open > > with Result-Code > > not = UNKNOWN-SESSION-ID > > So the other two response codes are DIAMETER_SUCCESS and > DIAMETER_UNABLE_TO_COMPLY. Should these both result in ignoring the > response? I might agree with the latter, but certainly not the > former! > > I suggest that DIAMETER_UNKNOWN_SESSION_ID and DIAMETER_SUCCESS be > used for the first event, and that the second simply use > DIAMETER_UNABLE_TO_COMPLY. The whole ASA handling seems a bit weird, now that I look at it. If we need to abort, we need to abort and clean up the state regardless of whether there was some problem somewhere which prevented us from doing so. The question is, is the error something that is temporary such as network partitioning, or something which is caused by a software problem at either end? If former, it makes sense to wait and retry. If latter, we really don't want to get into a loop here. There's two possible approaches to this. One approach is that we ignore the problem, and allow temporary problems to prevent abortions. Another approach is to make the state machine more complex and in a manner similar to the accounting state machine keep on trying if the problem is temporary. Perhaps the latter approach is more appropriate. I've added a new state for the server side, and dealt with different error codes in different manner. Please comment. Voice your opinion also if you wanted alternative #1. Jari --------------070006030406040708000703 Content-Type: text/plain; name="diamstates.txt" Content-Disposition: inline; filename="diamstates.txt" Content-Transfer-Encoding: 7bit 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service- Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN- SESSION-ID Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device Send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on Send STR Discon Access Device Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device Discon ASR Received Send ASA Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup Open Home server wants to Send ASR Discon terminate the service Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Idle home server Open STR Received Send STA, Idle Cleanup Discon ASA Received Cleanup Idle with Result-Code = SUCCESS Discon Unable to send ASR or Wait, Discon ASA Received Send ASR with Result-Code = TOO_BUSY or LOOP_DETECTED Discon ASA Received Cleanup Idle with Result-Code not = SUCCESS and not = TOO_BUSY and not = LOOP_DETECTED Not ASA Received None No Change. Discon Not STR Received Send STA, Idle Open Cleanup The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send serv. Idle request received, and specific successfully processed answer 8.2 Accounting Session State Machine For applications that only require accounting services or applications that have an accounting portion, the following state machines MUST be supported. The first is to be observed by clients, the second by servers. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send' means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. The event 'Failed answer' means that the Diameter client received a non-transient failure notification in the Accounting Answer command. Note that the action 'Disconnect user/dev' MUST have an effect also to the authorization session state table, e.g. cause the STR message to be sent, if the given application has both authentication/authorization and accounting portions. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests Send PendingS access accounting start req. Idle Client or device requests Send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE PendingS User service terminated Store PendingS stop record Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req. PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev not equal to GRANT_AND_LOSE PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available event record PendingE Failure to send and no buffer Idle space available PendingE Failed accounting event answer Idle received PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingB Failed accounting answer Delete Idle received record PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available stop record PendingL Failure to send and no buffer Idle space available PendingL Failed accounting stop answer Idle received SERVER, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Idle received, and successfully accounting processed. start answer Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Interim record received, Send Idle and successfully processed. accounting answer Idle Accounting stop request Send Idle received, and successfully accounting processed stop answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE --------------070006030406040708000703-- From owner-aaa-wg@merit.edu Mon Apr 1 14:40:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11700 for ; Mon, 1 Apr 2002 14:40:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A73FE91235; Mon, 1 Apr 2002 14:39:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7529491239; Mon, 1 Apr 2002 14:39:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4868591235 for ; Mon, 1 Apr 2002 14:39:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 205735DE1F; Mon, 1 Apr 2002 14:39:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id E12AF5DD9F for ; Mon, 1 Apr 2002 14:39:56 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g31Jdr913473; Mon, 1 Apr 2002 14:39:53 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA02425; Mon, 1 Apr 2002 13:39:53 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g31Jdqq28446; Mon, 1 Apr 2002 13:39:52 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.46984.455225.943613@nwsgpc.ih.lucent.com> Date: Mon, 1 Apr 2002 13:39:52 -0600 (CST) From: Pete McCann To: Jari Arkko Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Bug in Acct state machine In-Reply-To: <3CA893D9.6030002@kolumbus.fi> References: <3CA81A10.1030608@kolumbus.fi> <3CA849CD.1040208@kolumbus.fi> <15528.37676.452855.623719@nwsgpc.ih.lucent.com> <3CA893D9.6030002@kolumbus.fi> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jari, I agree with what you wrote, but perhaps a bit of clean-up can be done; the Accounting state machine defines the condition "Failure to Send" as including unable to reach peer, OUT_OF_SPACE, LOOP_DETECTED, or TOO_BUSY. Perhaps you can define a similar condition for the authorization session state, maybe without the OUT_OF_SPACE. Also, can't the following two actions be combined? > Discon ASA Received Cleanup Idle > with Result-Code > = SUCCESS > > Discon ASA Received Cleanup Idle > with Result-Code > not = SUCCESS and > not = TOO_BUSY and > not = LOOP_DETECTED Here you could use the complement of "Failure to Send" as the triggering event, and just cleanup and go to Idle no matter what is received. Also, > Pending Successful Service-specific Sent STR Discon > authorization answer received ^^^^ "Send" > but service not provided > > Pending Error processing successful Sent STR Discon > Service-specific authorization ^^^^ "Send" > answer Also, s/UNKNOWN-SESSION-ID/UNKNOWN_SESSION_ID -Pete Jari Arkko writes: > The whole ASA handling seems a bit weird, now that I look at it. > If we need to abort, we need to abort and clean up the state regardless > of whether there was some problem somewhere which prevented us > from doing so. The question is, is the error something that is temporary > such as network partitioning, or something which is caused by a software > problem at either end? If former, it makes sense to wait and retry. If > latter, we really don't want to get into a loop here. > > There's two possible approaches to this. One approach is that we ignore > the problem, and allow temporary problems to prevent abortions. Another > approach is to make the state machine more complex and in a manner similar > to the accounting state machine keep on trying if the problem is temporary. > > Perhaps the latter approach is more appropriate. I've added a new state > for the server side, and dealt with different error codes in different > manner. Please comment. Voice your opinion also if you wanted > alternative #1. From owner-aaa-wg@merit.edu Mon Apr 1 14:58:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12222 for ; Mon, 1 Apr 2002 14:58:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC6C39123A; Mon, 1 Apr 2002 14:58:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 784E59123B; Mon, 1 Apr 2002 14:58:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 395129123A for ; Mon, 1 Apr 2002 14:58:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 197CA5DE59; Mon, 1 Apr 2002 14:58:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5BB245DE1F for ; Mon, 1 Apr 2002 14:58:41 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31Jwu515966 for ; Mon, 1 Apr 2002 22:58:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:58:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:58:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 303: Security model for peer discovery andredirect - Text - Please Review Date: Mon, 1 Apr 2002 22:58:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E525@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 303: Security model for peer discovery andredirect - Text - Please Review Thread-Index: AcHXOB2J0qjGPMdSRvak2iQOsziEbwCayI3g From: To: Cc: , , X-OriginalArrivalTime: 01 Apr 2002 19:58:40.0059 (UTC) FILETIME=[9E4418B0:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12222 Hi Bernard, The text you suggested covered everything I intended, an more fully as well. I've added the text, so I consider 303 as CLOSED. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 29 March, 2002 16:17 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg@merit.edu; DSpence@Interlinknetworks.com; randy@psg.com > Subject: Re: [AAA-WG]: Issue 303: Security model for peer discovery > andredirect - Text - Please Review > > > > > > 13.3 Peer-to-Peer Considerations > > > > There are many security issues related to peer-to-peer > connections. Caution should be used when > >creating peer-to-peer connections. Diameter is not intended > to allow the > >peer-to-peer interface to be a public interface. > > I'd change this to the following: > > "As with any peer-to-peer protocol, proper configuration of the trust > model within a Diameter peer is essential to security. When > certificates > are used, it is necessary to configure the root certificate > authorities > trusted by the Diameter peer. These root CAs are likely to be > unique to > Diameter usage and distinct from the root CAs that might be > trusted for > other purposes such as Web browsing. In general, it is > expected that those root CAs will be configured so as to reflect the > business relationships between the organization hosting the > Diameter peer > and other organizations. As a result, a Diameter peer will > typically not > be configured to allow connectivity with any arbitrary peer. When > certificate authentication Diameter peers may not be known > beforehand, and > therefore peer discovery may be required. > > Note that IPsec is considerably less flexible than TLS when > it comes to > configuring root CAs. Since use of Port identifiers is > prohibited within > IKE Phase 1, within IPsec it is not possible to uniquely > configure trusted > root CAs for each application individually; the same policy > must be used > for all applications. This implies, for example, that a root CA > trusted for use with Diameter must also be trusted to protect > SNMP. These restrictions can be awkward at best. Since TLS supports > application-level granularity in certificate policy, TLS > SHOULD be used to > protect Diameter connections between administrative domains. > IPsec is most > appropriate for intra-domain usage when pre-shared keys are used as a > security mechanism. > > When pre-shared key authentication is used with IPsec to > protect Diameter, unique pre-shared keys are configured with Diameter > peers, who are identified by their IP address (Main Mode), or possibly > their FQDN (Aggressive Mode). As a result, it is necessary > for the set of > Diameter peers to be known beforehand. Therefore peer discovery is > typically not necessary. > > The following is intended to provide some guidance on the issue. > > > > A Diameter node SHOULD implement the same security > mechanism (IPsec or TLS) across > > all its peer-to-peer connections. Inconsistent use of security > > mechanisms can open security holes at a node. For example if a node > > using both TLS and IPsec, there is not good way in which a > connection > >that is not TLS-secured is, in fact, IPsec secured. Additionally, a > > per-peer policy would need to be installed, which, in > practice is quite > >hard to maintain. > > Suggested change: > > It is recommended that a Diameter peer implement the same security > mechanism (IPsec or TLS) across all its peer-to-peer > connections. Inconsistent use of security mechanisms can result in > redundant security mechanisms being used (e.g. TLS over > IPsec) or worse, > potential security vulnerabilities. When IPsec is used with > Diameter, a > typical security policy for outbound traffic is "Initiate > IPsec, From me > to any, destination port Diameter"; for inbound traffic, the > policy would > be "Require IPsec, From any to me, destination port Diameter". > > This policy causes IPsec to be used whenever a Diameter peer > initiates a > connection to another Diameter peer, and to be required whenever an > inbound Diameter connection occurs. This policy is > attractive, since it > does not require policy to be set for each peer or dynamically plumbed > each time a new Diameter connection is created; an IPsec SA is > automatically created based on a simple static policy. Since IPsec > extensions are typically not available to the sockets API on most > platforms, and IPsec policy functionality is implementation > dependent, use of a simple static policy is the often the > simplest route > to IPsec-enabling a Diameter implementation. > > One implication of the recommended policy is that if a node > is using both > TLS and IPsec, there is not a convenient way in which to use > either TLS or > IPsec, but not both, without reserving an additional port for > TLS usage. > Since Diameter uses the same port for TLS and non-TLS usage, where the > recommended IPsec policy is put in place, a TLS-protected > connection will > match the IPsec policy, and both IPsec and TLS will be used > to protect the > Diameter connection. To avoid this, it would be necessary to plumb > peer-specific policies either statically or dynamically. > > > > > If IPsec is used to secure the peer-to-peer connections to > a Diameter node, > >then there SHOULD be a mechanism to prevent non-IPsec > protected traffic > >from reaching the node. For example, a firewall or inbound filter > >policy. > > Change to: > > If IPsec is used to secure Diameter peer-to-peer connections, > IPsec policy > SHOULD be set so as to require IPsec protection for inbound > connections, > and to initiate IPsec protection for outbound connections. This can be > accomplished via use of inbound and outbound filter policy. > > > > > If IPsec is used and preconfigured SAs are not used, it is > not recommended to > > rely on a PKI-based solution. It is recommended that only > peer-to-peer > > connections are created within a domain, or the Diameter nodes of an > > organization you trust. > > By preconfigured SAs, do you mean manual SAs? Not sure what > we are saying > here; are we recommending against certificate-based > authentication with > IPsec? My recommendation is to delete the above paragraph. > > > > > > If TLS is used to secure peer-to-peer connections, it is > recommended that > >connections within a domain, or with the Diameter nodes of an > >organization you trust. > > I think this is covered by the above text. > > From owner-aaa-wg@merit.edu Mon Apr 1 14:59:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12247 for ; Mon, 1 Apr 2002 14:59:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D9429123D; Mon, 1 Apr 2002 14:58:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22AF79123E; Mon, 1 Apr 2002 14:58:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B3689123D for ; Mon, 1 Apr 2002 14:58:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD5AB5DE59; Mon, 1 Apr 2002 14:58:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2FD835DE1F for ; Mon, 1 Apr 2002 14:58:52 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31Jx6516063 for ; Mon, 1 Apr 2002 22:59:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:58:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:58:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 311:Acct-Application-Id and Vendor-Specific-Application-Id in ACR Date: Mon, 1 Apr 2002 22:58:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E52D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 311:Acct-Application-Id and Vendor-Specific-Application-Id in ACR Thread-Index: AcHWkOI0h7gTXEj6Rnu4Mg2hQs+F9wDIGGVA From: To: Cc: X-OriginalArrivalTime: 01 Apr 2002 19:58:50.0886 (UTC) FILETIME=[A4B82A60:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12247 Hi Jari, Got the changes, some confirmations in-line. John > 5) Modify ANF for ACR as follows: > > ::= < Diameter Header: 271, REQ, PXY > > < Session-Id > > { ... } > [ Acct-Application-Id ] > [ Vendor-Specific-Application-Id ] > [ ... ] So, ACR becomes: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Accounting-RADIUS-Session-Id ] [ Acct-Multi-Session-Id ] [ Accounting-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] > 9) Modify AVP occurrence tables appropriately. Is this correct: Acct-Application-Id | 0-1 | 0-1 | Vendor-Specific-Application-Id| 0-1 | 0-1 | > > 10) 6.1.1 add Vendor-Specific-Application-Id to the list in > the last bullet. > > 11) Add a new paragraph after the first paragraph of 11.3: > "Both Application-Id > and Acct-Application-Id AVPs use the same Application > Identifier space." > > 12) Also add to 11 that not just zero but also 0xffffffff are > reserved values. > > > From owner-aaa-wg@merit.edu Mon Apr 1 14:59:39 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12264 for ; Mon, 1 Apr 2002 14:59:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7A619123C; Mon, 1 Apr 2002 14:58:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBA489123B; Mon, 1 Apr 2002 14:58:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D06879123C for ; Mon, 1 Apr 2002 14:58:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id B72D65DE59; Mon, 1 Apr 2002 14:58:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 09F7F5DE1F for ; Mon, 1 Apr 2002 14:58:44 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31Jvvu29200 for ; Mon, 1 Apr 2002 22:57:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:58:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:58:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Accounting-Realtime-Required Date: Mon, 1 Apr 2002 22:58:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E527@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Accounting-Realtime-Required Thread-Index: AcHXOXIOz5LH7OatQemViebtDCqF0wCbHcOw From: To: , Cc: X-OriginalArrivalTime: 01 Apr 2002 19:58:42.0793 (UTC) FILETIME=[9FE54590:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12264 Hi Bernard, This is a good catch, the change has been made, so this issue can be marked closed. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 29 March, 2002 16:23 > To: Pete McCann > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Accounting-Realtime-Required > > > Assigned #319. > > On Thu, 28 Mar 2002, Pete McCann wrote: > > > > > Issue: Accounting-Realtime-Required should appear > > in Section 9.7.2, and text in > Section 9.8.7 > > should give its AVP Code > > Submitter name: Pete McCann > > Submitter email address: mccap@lucent.com > > Date first submitted: 03-28-2002 > > Reference: > > Document: diameter-base-09 > > Comment type: Editorial > > Priority: 1 > > Section: 9.7.2, 9.8.7 > > > > Rationale: > > > > The Accounting-Realtime-Required AVP is defined in Section > 9.8.7, but > > is not mentioned in the ABNF for Accounting-Answer messages > in Section > > 9.7.2. Also, the description in Section 9.8.7 lists the AVP Code as > > "TBD", but the table on page 50-51 lists the AVP with Code 483. > > > > Requested Change: > > > > Add the following line to 9.7.2, > > after "[Accounting-Interim-Interval]": > > > > [ Accounting-Realtime-Required ] > > > > Change the first line of Section 9.8.7 to read: > > > > The Accounting-Realtime-Required AVP (AVP Code 483) is of type > > > > > > > > -Pete > > > > From owner-aaa-wg@merit.edu Mon Apr 1 15:00:09 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12294 for ; Mon, 1 Apr 2002 15:00:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC57291240; Mon, 1 Apr 2002 14:59:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 737D091242; Mon, 1 Apr 2002 14:59:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFE2191240 for ; Mon, 1 Apr 2002 14:59:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id C10305DE1F; Mon, 1 Apr 2002 14:59:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B40995DE59 for ; Mon, 1 Apr 2002 14:59:10 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31JxP516194 for ; Mon, 1 Apr 2002 22:59:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:59:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:59:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1D9B7.AF76B0FF" Subject: RE: [AAA-WG]: Re: Bug in Acct state machine Date: Mon, 1 Apr 2002 22:59:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E52E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: yes Thread-Topic: [AAA-WG]: Re: Bug in Acct state machine Thread-Index: AcHZiBVpmLRsP8EWSN+SJlCwtNue2wALAifw From: To: , , X-OriginalArrivalTime: 01 Apr 2002 19:59:09.0042 (UTC) FILETIME=[AF8A8D20:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D9B7.AF76B0FF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I've made the changes according to this text, please let me know if = anything still needs some updating. John ------_=_NextPart_001_01C1D9B7.AF76B0FF Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Apr 2002 17:18:23 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1D988.14C02180" Received: from esvir10nok.ntc.nokia.com ([172.21.143.42]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 17:18:22 +0300 Received: from mgw-x4.nokia.com (unverified) by esvir10nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 17:18:23 +0300 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31EREO02872; Mon, 1 Apr 2002 17:27:14 +0300 (EET DST) Received: by trapdoor.merit.edu (Postfix) id 65AA891236; Mon, 1 Apr 2002 09:18:10 -0500 (EST) content-class: urn:content-classes:message Subject: [AAA-WG]: Re: Bug in Acct state machine Date: Mon, 1 Apr 2002 14:51:41 +0300 Message-ID: <3CA849CD.1040208@kolumbus.fi> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Re: Bug in Acct state machine Thread-Index: AcHZiBVpmLRsP8EWSN+SJlCwtNue2w== From: To: , This is a multi-part message in MIME format. ------_=_NextPart_002_01C1D988.14C02180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > >Shouldn't the above be: > > Discon ASR Received Send STA. Discon >=20 > Not quite. The STA is sent by the server, not the client. >=20 > There is an issue, however, on what to do if we have already sent an = STR, > are waiting for the STA to arrive but then we get an ASR from the = server > (STR and ASR meet on the wire). The -09 state machine simply ignored = the > ASR in this case, and on the server side was able to terminate the = session > if, while waiting for ASA would instead get STR. I think Pete's state > machine gets it right as well. On second thought, and on reading section 8.5, it seems that the more appropriate action is really answering the ASR also. The ASR could come from some other server than the one we sent the STR to. So, if we are in the progress of releasing the session already and we get ASR, we should respond with ASA Result-Code =3D Success. Modified state machine attached. Jari ------_=_NextPart_002_01C1D988.14C02180 Content-Type: text/plain; name="diamstates.txt" Content-Description: diamstates.txt Content-Disposition: inline; filename="diamstates.txt" Content-Transfer-Encoding: base64 DQo4LjEgIEF1dGhvcml6YXRpb24gU2Vzc2lvbiBTdGF0ZSBNYWNoaW5lDQoNCiAgIFRoaXMgc2Vj dGlvbiBjb250YWlucyBhIHNldCBvZiBmaW5pdGUgc3RhdGUgbWFjaGluZXMsIHJlcHJlc2VudGlu ZyB0aGUgbGlmZQ0KICAgY3ljbGUgb2YgRGlhbWV0ZXIgc2Vzc2lvbnMsIGFuZCB3aGljaCBNVVNU IGJlIG9ic2VydmVkIGJ5IGFsbCBEaWFtZXRlcg0KICAgaW1wbGVtZW50YXRpb25zIHRoYXQgbWFr ZSB1c2Ugb2YgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZC9vcg0KICAgYXV0aG9yaXphdGlvbiBwb3J0 aW9uIG9mIGEgRGlhbWV0ZXIgYXBwbGljYXRpb24uIFRoZSB0ZXJtIFNlcnZpY2UtDQogICBTcGVj aWZpYyBiZWxvdyByZWZlcnMgdG8gYSBtZXNzYWdlIGRlZmluZWQgaW4gYSBEaWFtZXRlciBhcHBs aWNhdGlvbg0KICAgKGUuZy4gTW9iaWxlIElQLCBOQVNSRVEpLg0KDQogICBUaGVyZSBhcmUgZm91 ciBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBzZXNzaW9uIHN0YXRlIG1hY2hpbmVzDQogICBzdXBw b3J0ZWQgaW4gdGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wuIFRoZSBmaXJzdCB0d28gZGVzY3Jp YmUgYQ0KICAgc2Vzc2lvbiBpbiB3aGljaCB0aGUgc2VydmVyIGlzIG1haW50YWluaW5nIHNlc3Np b24gc3RhdGUsIGluZGljYXRlZA0KICAgYnkgdGhlIHZhbHVlIG9mIHRoZSBBdXRoLVNlc3Npb24t U3RhdGUgQVZQIChvciBpdHMgYWJzZW5jZSkuICBPbmUNCiAgIGRlc2NyaWJlcyB0aGUgc2Vzc2lv biBmcm9tIGEgY2xpZW50IHBlcnNwZWN0aXZlLCB0aGUgb3RoZXIgZnJvbSBhDQogICBzZXJ2ZXIg cGVyc3BlY3RpdmUuIFRoZSBzZWNvbmQgdHdvIHN0YXRlIG1hY2hpbmVzIGFyZSB1c2VkIHdoZW4N CiAgIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbWFpbnRhaW4gc2Vzc2lvbiBzdGF0ZS4gSGVyZSBhZ2Fp biwgb25lDQogICBkZXNjcmliZXMgdGhlIHNlc3Npb24gZnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2 ZSwgdGhlIG90aGVyIGZyb20gYQ0KICAgc2VydmVyIHBlcnNwZWN0aXZlLg0KDQogICBXaGVuIGEg c2Vzc2lvbiBpcyBtb3ZlZCB0byB0aGUgSWRsZSBzdGF0ZSwgYW55IHJlc291cmNlcyB0aGF0IHdl cmUNCiAgIGFsbG9jYXRlZCBmb3IgdGhlIHBhcnRpY3VsYXIgc2Vzc2lvbiBtdXN0IGJlIHJlbGVh c2VkLiAgQW55IGV2ZW50IG5vdA0KICAgbGlzdGVkIGluIHRoZSBzdGF0ZSBtYWNoaW5lcyBNVVNU IGJlIGNvbnNpZGVyZWQgYXMgYW4gZXJyb3INCiAgIGNvbmRpdGlvbiwgYW5kIGFuIGFuc3dlciwg aWYgYXBwbGljYWJsZSwgTVVTVCBiZSByZXR1cm5lZCB0byB0aGUNCiAgIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFjaGluZSBpcyBvYnNlcnZl ZCBieSBhIGNsaWVudCB3aGVuIHN0YXRlIGlzDQogICBtYWludGFpbmVkIG9uIHRoZSBzZXJ2ZXI6 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENMSUVOVCwgU1RBVEVGVUwNCiAgICAg IFN0YXRlICAgICBFdmVudCAgICAgICAgICAgICAgICAgICAgICAgICAgQWN0aW9uICAgICBOZXcg U3RhdGUNCiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIElkbGUgICAgICBDbGllbnQgb3IgRGV2aWNlIFJlcXVl c3RzICAgICAgU2VuZCAgICAgICBQZW5kaW5nDQogICAgICAgICAgICAgICAgYWNjZXNzICAgICAg ICAgICAgICAgICAgICAgICAgIHNlcnZpY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYXV0aCByZXENCg0KICAgICAgSWRsZSAgICAgIEFTUiBSZWNlaXZl ZCAgICAgICAgICAgICAgICAgICBTZW5kIEFTQSAgIElkbGUNCiAgICAgICAgICAgICAgICBmb3Ig dW5rbm93biBzZXNzaW9uICAgICAgICAgICAgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSZXN1bHQtQ29kZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IFVOS05PV04tDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNFU1NJT04tSUQNCg0KICAgICAgUGVuZGluZyAg IFN1Y2Nlc3NmdWwgU2VydmljZS1zcGVjaWZpYyAgICBHcmFudCAgICAgIE9wZW4NCiAgICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAgICAgQWNjZXNzDQogICAgICAgICAg ICAgICAgcmVjZWl2ZWQgd2l0aCBkZWZhdWx0DQogICAgICAgICAgICAgICAgQXV0aC1TZXNzaW9u LVN0YXRlIHZhbHVlDQoNCiAgICAgIFBlbmRpbmcgICBTdWNjZXNzZnVsIFNlcnZpY2Utc3BlY2lm aWMgICAgU2VudCBTVFIgICBEaXNjb24NCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGFu c3dlciByZWNlaXZlZA0KICAgICAgICAgICAgICAgIGJ1dCBzZXJ2aWNlIG5vdCBwcm92aWRlZA0K DQogICAgICBQZW5kaW5nICAgRXJyb3IgcHJvY2Vzc2luZyBzdWNjZXNzZnVsICAgIFNlbnQgU1RS ICAgRGlzY29uDQogICAgICAgICAgICAgICAgU2VydmljZS1zcGVjaWZpYyBhdXRob3JpemF0aW9u DQogICAgICAgICAgICAgICAgYW5zd2VyDQoNCiAgICAgIFBlbmRpbmcgICBGYWlsZWQgU2Vydmlj ZS1zcGVjaWZpYyAgICAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAgYXV0aG9y aXphdGlvbiBhbnN3ZXIgcmVjZWl2ZWQNCg0KICAgICAgT3BlbiAgICAgIHVzZXIgb3IgY2xpZW50 IGRldmljZSAgICAgICAgICBTZW5kICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICByZXF1ZXN0 cyBhY2Nlc3MgdG8gc2VydmljZSAgICAgc2VydmljZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpYw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhdXRoIHJlcQ0KDQogICAgICBPcGVuICAgICAgU3VjY2Vz c2Z1bCBTZXJ2aWNlLXNwZWNpZmljICAgIEV4dGVuZCAgICAgT3Blbg0KICAgICAgICAgICAgICAg IGF1dGhvcml6YXRpb24gYW5zd2VyIHJlY2VpdmVkICBBbnN3ZXINCg0KICAgICAgT3BlbiAgICAg IEZhaWxlZCBTZXJ2aWNlLXNwZWNpZmljICAgICAgICBEaXNjb24uICAgIElkbGUNCiAgICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAgICAgdXNlci9kZXZpY2UNCiAgICAg ICAgICAgICAgICByZWNlaXZlZC4NCg0KICAgICAgT3BlbiAgICAgIFNlc3Npb24tVGltZW91dCBF eHBpcmVzIG9uICAgICBTZW5kIFNUUiAgIERpc2Nvbg0KICAgICAgICAgICAgICAgIEFjY2VzcyBE ZXZpY2UNCg0KICAgICAgT3BlbiAgICAgIEFTUiBSZWNlaXZlZCwgICAgICAgICAgICAgICAgICBT ZW5kIEFTQSAgIERpc2Nvbg0KICAgICAgICAgICAgICAgIGNsaWVudCB3aWxsIGNvbXBseSB3aXRo ICAgICAgICB3aXRoDQogICAgICAgICAgICAgICAgcmVxdWVzdCB0byBlbmQgdGhlIHNlc3Npb24g ICAgIFJlc3VsdC1Db2RlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID0gU1VDQ0VTUywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2VuZCBTVFIuDQoNCiAgICAgIE9wZW4gICAgICBBU1IgUmVjZWl2ZWQsICAgICAg ICAgICAgICAgICAgU2VuZCBBU0EgICBPcGVuDQogICAgICAgICAgICAgICAgY2xpZW50IHdpbGwg bm90IGNvbXBseSB3aXRoICAgIHdpdGgNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHRvIGVuZCB0 aGUgc2Vzc2lvbiAgICAgUmVzdWx0LUNvZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIT0gU1VDQ0VTUw0KDQogICAgICBPcGVuICAgICAgQXV0aG9yaXph dGlvbi1MaWZldGltZSArICAgICAgIFNlbmQgU1RSICAgRGlzY29uDQogICAgICAgICAgICAgICAg QXV0aC1HcmFjZS1QZXJpb2QgZXhwaXJlcyBvbg0KICAgICAgICAgICAgICAgIGFjY2VzcyBkZXZp Y2UNCg0KICAgICAgRGlzY29uICAgIEFTUiBSZWNlaXZlZCAgICAgICAgICAgICAgICAgICBTZW5k IEFTQSAgIERpc2Nvbg0KDQogICAgICBEaXNjb24gICAgU1RBIFJlY2VpdmVkICAgICAgICAgICAg ICAgICAgIERpc2Nvbi4gICAgSWRsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1c2VyL2RldmljZQ0KDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFj aGluZSBpcyBvYnNlcnZlZCBieSBhIHNlcnZlciB3aGVuIGl0IGlzDQogICBtYWludGFpbmluZyBz dGF0ZSBmb3IgdGhlIHNlc3Npb246DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0VS VkVSLCBTVEFURUZVTA0KICAgICAgU3RhdGUgICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAg ICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgSWRsZSAgICAgIFNl cnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBTZW5kICAgICAgIE9wZW4NCiAgICAgICAgICAg ICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQgICAgICAgICAgc3VjY2Vzc2Z1bA0KICAgICAgICAg ICAgICAgIHVzZXIgaXMgYXV0aG9yaXplZCAgICAgICAgICAgICBzZXJ2Lg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpYyBhbnN3ZXINCg0KICAg ICAgSWRsZSAgICAgIFNlcnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBTZW5kICAgICAgIElk bGUNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQgICAgICAgICAgZmFpbGVk IHNlcnYuDQogICAgICAgICAgICAgICAgdXNlciBpcyBub3QgYXV0aG9yaXplZCAgICAgICAgIHNw ZWNpZmljIGFuc3dlcg0KDQogICAgICBPcGVuICAgICAgU2VydmljZS1zcGVjaWZpYyBhdXRob3Jp emF0aW9uIFNlbmQgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIHJlcXVlc3QgcmVjZWl2ZWQs IGFuZCB1c2VyICAgICBzdWNjZXNzZnVsDQogICAgICAgICAgICAgICAgaXMgYXV0aG9yaXplZCAg ICAgICAgICAgICAgICAgIHNlcnYuIHNwZWNpZmljDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBPcGVuICAgICAgU2VydmljZS1z cGVjaWZpYyBhdXRob3JpemF0aW9uIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJl cXVlc3QgcmVjZWl2ZWQsIGFuZCB1c2VyICAgICBmYWlsZWQgc2Vydi4NCiAgICAgICAgICAgICAg ICBpcyBub3QgYXV0aG9yaXplZCAgICAgICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5zd2VyLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDbGVhbnVwDQoNCiAgICAgIE9wZW4gICAg ICBIb21lIHNlcnZlciB3YW50cyB0byAgICAgICAgICAgU2VuZCBBU1IgICBPcGVuDQogICAgICAg ICAgICAgICAgdGVybWluYXRlIHRoZSBzZXJ2aWNlDQoNCiAgICAgIE9wZW4gICAgICBBU0EgUmVj ZWl2ZWQgICAgICAgICAgICAgICAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAg d2l0aCBSZXN1bHQtQ29kZQ0KICAgICAgICAgICAgICAgID0gVU5LTk9XTi1TRVNTSU9OLUlEDQoN CiAgICAgIE9wZW4gICAgICBBU0EgUmVjZWl2ZWQgICAgICAgICAgICAgICAgICAgTm9uZSAgICAg ICBPcGVuDQogICAgICAgICAgICAgICAgd2l0aCBSZXN1bHQtQ29kZSAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgIG5vdCA9IFVOS05PV04tU0VTU0lPTi1JRA0KDQogICAgICBPcGVuICAg ICAgQXV0aG9yaXphdGlvbi1MaWZldGltZSAoYW5kICAgIENsZWFudXAgICAgSWRsZQ0KICAgICAg ICAgICAgICAgIEF1dGgtR3JhY2UtUGVyaW9kKSBleHBpcmVzDQogICAgICAgICAgICAgICAgb24g aG9tZSBzZXJ2ZXIuDQoNCiAgICAgIE9wZW4gICAgICBTZXNzaW9uLVRpbWVvdXQgZXhwaXJlcyBv biAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAgaG9tZSBzZXJ2ZXINCg0KICAg ICAgT3BlbiAgICAgIFNUUiBSZWNlaXZlZCAgICAgICAgICAgICAgICAgICBTZW5kIFNUQSwgIElk bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xlYW51 cA0KDQogICAgICBOb3QgICAgICAgQVNBIFJlY2VpdmVkICAgICAgICAgICAgICAgICAgIE5vbmUg ICAgICAgTm8gQ2hhbmdlLg0KICAgICAgT3Blbg0KDQogICAgICBOb3QgICAgICAgU1RSIFJlY2Vp dmVkICAgICAgICAgICAgICAgICAgIFNlbmQgU1RBLCAgSWRsZQ0KICAgICAgT3BlbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDbGVhbnVwDQoNCg0KDQogICBUaGUgZm9sbG93 aW5nIHN0YXRlIG1hY2hpbmUgaXMgb2JzZXJ2ZWQgYnkgYSBjbGllbnQgd2hlbiBzdGF0ZSBpcw0K ICAgbm90IG1haW50YWluZWQgb24gdGhlIHNlcnZlcjoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ0xJRU5ULCBTVEFURUxFU1MNCiAgICAgIFN0YXRlICAgICBFdmVudCAgICAgICAg ICAgICAgICAgICAgICAgICAgQWN0aW9uICAgICBOZXcgU3RhdGUNCiAgICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg IElkbGUgICAgICBDbGllbnQgb3IgRGV2aWNlIFJlcXVlc3RzICAgICAgU2VuZCAgICAgICBQZW5k aW5nDQogICAgICAgICAgICAgICAgYWNjZXNzICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZp Y2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lm aWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXV0aCBy ZXENCg0KICAgICAgUGVuZGluZyAgIFN1Y2Nlc3NmdWwgU2VydmljZS1zcGVjaWZpYyAgICBHcmFu dCAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAg ICAgQWNjZXNzDQogICAgICAgICAgICAgICAgcmVjZWl2ZWQgd2l0aCBBdXRoLVNlc3Npb24tDQog ICAgICAgICAgICAgICAgU3RhdGUgc2V0IHRvDQogICAgICAgICAgICAgICAgTk9fU1RBVEVfTUFJ TlRBSU5FRA0KDQogICAgICBQZW5kaW5nICAgRmFpbGVkIFNlcnZpY2Utc3BlY2lmaWMgICAgICAg IENsZWFudXAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gYW5zd2VyDQog ICAgICAgICAgICAgICAgcmVjZWl2ZWQNCg0KICAgICAgT3BlbiAgICAgIFNlc3Npb24tVGltZW91 dCBFeHBpcmVzIG9uICAgICBEaXNjb24uICAgIElkbGUNCiAgICAgICAgICAgICAgICBBY2Nlc3Mg RGV2aWNlICAgICAgICAgICAgICAgICAgdXNlci9kZXZpY2UNCg0KICAgICAgT3BlbiAgICAgIFNl cnZpY2UgdG8gdXNlciBpcyB0ZXJtaW5hdGVkICBEaXNjb24uICAgIElkbGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlci9kZXZpY2UNCg0KDQoNCiAg IFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFjaGluZSBpcyBvYnNlcnZlZCBieSBhIHNlcnZlciB3aGVu IGl0IGlzIG5vdA0KICAgbWFpbnRhaW5pbmcgc3RhdGUgZm9yIHRoZSBzZXNzaW9uOg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIsIFNUQVRFTEVTUw0KICAgICAgU3RhdGUg ICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0K ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KICAgICAgSWRsZSAgICAgIFNlcnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlv biBTZW5kIHNlcnYuIElkbGUNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQg ICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICBzdWNjZXNzZnVsbHkgcHJvY2Vzc2Vk ICAgICAgICAgYW5zd2VyDQoNCg0KOC4yICBBY2NvdW50aW5nIFNlc3Npb24gU3RhdGUgTWFjaGlu ZQ0KDQogICBGb3IgYXBwbGljYXRpb25zIHRoYXQgb25seSByZXF1aXJlIGFjY291bnRpbmcgc2Vy dmljZXMgb3INCiAgIGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgYW4gYWNjb3VudGluZyBwb3J0aW9u LCB0aGUgZm9sbG93aW5nIHN0YXRlDQogICBtYWNoaW5lcyBNVVNUIGJlIHN1cHBvcnRlZC4gVGhl IGZpcnN0IGlzIHRvIGJlIG9ic2VydmVkIGJ5IGNsaWVudHMsDQogICB0aGUgc2Vjb25kIGJ5IHNl cnZlcnMuDQoNCiAgIFdoZW4gYSBzZXNzaW9uIGlzIG1vdmVkIHRvIHRoZSBJZGxlIHN0YXRlLCBh bnkgcmVzb3VyY2VzIHRoYXQgd2VyZQ0KICAgYWxsb2NhdGVkIGZvciB0aGUgcGFydGljdWxhciBz ZXNzaW9uIG11c3QgYmUgcmVsZWFzZWQuICBBbnkgZXZlbnQgbm90DQogICBsaXN0ZWQgaW4gdGhl IHN0YXRlIG1hY2hpbmVzIE1VU1QgYmUgY29uc2lkZXJlZCBhcyBhbiBlcnJvcg0KICAgY29uZGl0 aW9uLCBhbmQgYW4gYW5zd2VyLCBpZiBhcHBsaWNhYmxlLCBNVVNUIGJlIHJldHVybmVkIHRvIHRo ZQ0KICAgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4NCg0KICAgSW4gdGhlIHN0YXRlIHRhYmxl LCB0aGUgZXZlbnQgJ0ZhaWx1cmUgdG8gc2VuZCcgbWVhbnMgdGhhdCB0aGUNCiAgIERpYW1ldGVy IGNsaWVudCBpcyB1bmFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgZGVzaXJlZA0KICAgZGVz dGluYXRpb24uIFRoaXMgY291bGQgYmUgZHVlIHRvIHRoZSBwZWVyIGJlaW5nIGRvd24sIG9yIGR1 ZSB0bw0KICAgdGhlIHBlZXIgc2VuZGluZyBiYWNrIGEgdHJhbnNpZW50IGZhaWx1cmUgb3IgdGVt cG9yYXJ5IHByb3RvY29sDQogICBlcnJvciBub3RpZmljYXRpb24gRElBTUVURVJfT1VUX09GX1NQ QUNFLCBESUFNRVRFUl9UT09fQlVTWSwgb3INCiAgIERJQU1FVEVSX0xPT1BfREVURUNURUQgaW4g dGhlIFJlc3VsdC1Db2RlIEFWUCBvZiB0aGUgQWNjb3VudGluZw0KICAgQW5zd2VyIGNvbW1hbmQu DQoNCiAgIFRoZSBldmVudCAnRmFpbGVkIGFuc3dlcicgbWVhbnMgdGhhdCB0aGUgRGlhbWV0ZXIg Y2xpZW50IHJlY2VpdmVkIGENCiAgIG5vbi10cmFuc2llbnQgZmFpbHVyZSBub3RpZmljYXRpb24g aW4gdGhlIEFjY291bnRpbmcgQW5zd2VyDQogICBjb21tYW5kLg0KDQogICBOb3RlIHRoYXQgdGhl IGFjdGlvbiAnRGlzY29ubmVjdCB1c2VyL2RldicgTVVTVCBoYXZlIGFuIGVmZmVjdCBhbHNvDQog ICB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXNzaW9uIHN0YXRlIHRhYmxlLCBlLmcuIGNhdXNlIHRo ZSBTVFINCiAgIG1lc3NhZ2UgdG8gYmUgc2VudCwgaWYgdGhlIGdpdmVuIGFwcGxpY2F0aW9uIGhh cyBib3RoDQogICBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIHBv cnRpb25zLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDTElFTlQsIEFDQ09VTlRJ TkcNCiAgICAgIFN0YXRlICAgICBFdmVudCAgICAgICAgICAgICAgICAgICAgICAgICAgQWN0aW9u ICAgICBOZXcgU3RhdGUNCiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIElkbGUgICAgICBDbGllbnQgb3IgZGV2 aWNlIHJlcXVlc3RzICAgICAgU2VuZCAgICAgICBQZW5kaW5nUw0KICAgICAgICAgICAgICAgIGFj Y2VzcyAgICAgICAgICAgICAgICAgICAgICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXJ0IHJlcS4NCg0KICAgICAgSWRsZSAg ICAgIENsaWVudCBvciBkZXZpY2UgcmVxdWVzdHMgICAgICBTZW5kICAgICAgIFBlbmRpbmdFDQog ICAgICAgICAgICAgICAgYSBvbmUtdGltZSBzZXJ2aWNlICAgICAgICAgICAgIGFjY291bnRpbmcN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXZlbnQgcmVx DQoNCiAgICAgIElkbGUgICAgICBSZWNvcmRzIGluIHN0b3JhZ2UgICAgICAgICAgICAgU2VuZCAg ICAgICBQZW5kaW5nQg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZWNvcmQNCg0KICAgICAgUGVuZGluZ1MgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyAgICAg ICAgICAgICAgICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzdGFydCBhbnN3ZXIgcmVjZWl2 ZWQNCg0KICAgICAgUGVuZGluZ1MgIEZhaWx1cmUgdG8gc2VuZCBhbmQgYnVmZmVyICAgICBTdG9y ZSAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgYW5kIHJlYWx0aW1l ICAgU3RhcnQNCiAgICAgICAgICAgICAgICBub3QgZXF1YWwgdG8gREVMSVZFUl9BTkRfR1JBTlQg UmVjb3JkDQoNCiAgICAgIFBlbmRpbmdTICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAg ICAgICAgICAgICBPcGVuDQogICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlIGFuZCByZWFs dGltZQ0KICAgICAgICAgICAgICAgIGVxdWFsIHRvIEdSQU5UX0FORF9MT1NFDQoNCiAgICAgIFBl bmRpbmdTICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAgRGlzY29ubmVjdCBJZGxlDQog ICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlIGFuZCByZWFsdGltZSAgIHVzZXIvZGV2DQog ICAgICAgICAgICAgICAgbm90IGVxdWFsIHRvDQogICAgICAgICAgICAgICAgR1JBTlRfQU5EX0xP U0UNCg0KICAgICAgUGVuZGluZ1MgIEZhaWxlZCBhY2NvdW50aW5nIHN0YXJ0IGFuc3dlciAgICAg ICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICByZWNlaXZlZCBhbmQgcmVhbHRpbWUgZXF1YWwN CiAgICAgICAgICAgICAgICB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQZW5kaW5nUyAgRmFp bGVkIGFjY291bnRpbmcgc3RhcnQgYW5zd2VyIERpc2Nvbm5lY3QgSWRsZQ0KICAgICAgICAgICAg ICAgIHJlY2VpdmVkIGFuZCByZWFsdGltZSBub3QgICAgICB1c2VyL2Rldg0KICAgICAgICAgICAg ICAgIGVxdWFsIHRvIEdSQU5UX0FORF9MT1NFDQoNCiAgICAgIFBlbmRpbmdTICBVc2VyIHNlcnZp Y2UgdGVybWluYXRlZCAgICAgICAgU3RvcmUgICAgICBQZW5kaW5nUw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdG9wDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBPcGVuICAgICAgSW50 ZXJpbSBpbnRlcnZhbCBlbGFwc2VzICAgICAgIFNlbmQgICAgICAgUGVuZGluZ0kNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3VudGluZw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcmltDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBP cGVuICAgICAgVXNlciBzZXJ2aWNlIHRlcm1pbmF0ZWQgICAgICAgIFNlbmQgICAgICAgUGVuZGlu Z0wNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3Vu dGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdG9w IHJlcS4NCg0KICAgICAgUGVuZGluZ0kgIEZhaWx1cmUgdG8gc2VuZCBhbmQgKGJ1ZmZlciAgICBT dG9yZSAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgb3Igb2xkIHJl Y29yZCAgaW50ZXJpbQ0KICAgICAgICAgICAgICAgIGNhbiBiZSBvdmVyd3JpdHRlbikgYW5kICAg ICAgICByZWNvcmQNCiAgICAgICAgICAgICAgICByZWFsdGltZSBub3QgZXF1YWwgdG8NCiAgICAg ICAgICAgICAgICBERUxJVkVSX0FORF9HUkFOVA0KDQogICAgICBQZW5kaW5nSSAgRmFpbHVyZSB0 byBzZW5kIGFuZCBubyBidWZmZXIgICAgICAgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIHNw YWNlIGF2YWlsYWJsZSBhbmQgcmVhbHRpbWUNCiAgICAgICAgICAgICAgICBlcXVhbCB0byBHUkFO VF9BTkRfTE9TRQ0KDQogICAgICBQZW5kaW5nSSAgRmFpbHVyZSB0byBzZW5kIGFuZCBubyBidWZm ZXIgIERpc2Nvbm5lY3QgSWRsZQ0KICAgICAgICAgICAgICAgIHNwYWNlIGF2YWlsYWJsZSBhbmQg cmVhbHRpbWUgICB1c2VyL2Rldg0KICAgICAgICAgICAgICAgIG5vdCBlcXVhbCB0byBHUkFOVF9B TkRfTE9TRQ0KDQogICAgICBQZW5kaW5nSSAgRmFpbGVkIGFjY291bnRpbmcgaW50ZXJpbSAgICAg ICAgICAgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIGFuc3dlciByZWNlaXZlZCBhbmQgcmVh bHRpbWUNCiAgICAgICAgICAgICAgICBlcXVhbCB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQ ZW5kaW5nSSAgRmFpbGVkIGFjY291bnRpbmcgaW50ZXJpbSAgICAgIERpc2Nvbm5lY3QgSWRsZQ0K ICAgICAgICAgICAgICAgIGFuc3dlciByZWNlaXZlZCBhbmQgcmVhbHRpbWUgICB1c2VyL2Rldg0K ICAgICAgICAgICAgICAgIG5vdCBlcXVhbCB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQZW5k aW5nSSAgVXNlciBzZXJ2aWNlIHRlcm1pbmF0ZWQgICAgICAgIFN0b3JlICAgICAgUGVuZGluZ0kN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RvcA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWNvcmQNCg0KICAg ICAgUGVuZGluZ0UgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyAgICAgICAgICAgICAgICAgICAgIElk bGUNCiAgICAgICAgICAgICAgICBldmVudCBhbnN3ZXIgcmVjZWl2ZWQNCg0KICAgICAgUGVuZGlu Z0UgIEZhaWx1cmUgdG8gc2VuZCBhbmQgYnVmZmVyICAgICBTdG9yZSAgICAgIElkbGUNCiAgICAg ICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgICAgICAgICAgICAgICAgZXZlbnQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBl bmRpbmdFICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAgICAgICAgICAgICBJZGxlDQog ICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlDQoNCiAgICAgIFBlbmRpbmdFICBGYWlsZWQg YWNjb3VudGluZyBldmVudCBhbnN3ZXIgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAg cmVjZWl2ZWQNCg0KICAgICAgUGVuZGluZ0IgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyBhbnN3ZXIg ICBEZWxldGUgICAgIElkbGUNCiAgICAgICAgICAgICAgICByZWNlaXZlZCAgICAgICAgICAgICAg ICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBlbmRpbmdCICBGYWlsdXJlIHRvIHNlbmQgICAgICAg ICAgICAgICAgICAgICAgICAgICBJZGxlDQoNCiAgICAgIFBlbmRpbmdCICBGYWlsZWQgYWNjb3Vu dGluZyBhbnN3ZXIgICAgICAgRGVsZXRlICAgICBJZGxlDQogICAgICAgICAgICAgICAgcmVjZWl2 ZWQgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBQZW5kaW5nTCAgU3VjY2Vz c2Z1bCBhY2NvdW50aW5nICAgICAgICAgICAgICAgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAg IHN0b3AgYW5zd2VyIHJlY2VpdmVkDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsdXJlIHRvIHNlbmQg YW5kIGJ1ZmZlciAgICAgU3RvcmUgICAgICBJZGxlDQogICAgICAgICAgICAgICAgc3BhY2UgYXZh aWxhYmxlICAgICAgICAgICAgICAgIHN0b3ANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsdXJlIHRvIHNl bmQgYW5kIG5vIGJ1ZmZlciAgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAgc3BhY2Ug YXZhaWxhYmxlDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsZWQgYWNjb3VudGluZyBzdG9wIGFuc3dl ciAgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAgcmVjZWl2ZWQNCg0KDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNFUlZFUiwgQUNDT1VOVElORw0KICAgICAgU3RhdGUg ICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0K ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogICAgICBJZGxlICAgICAgQWNjb3VudGluZyBzdGFydCByZXF1ZXN0ICAg ICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJlY2VpdmVkLCBhbmQgc3VjY2Vz c2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgcHJvY2Vzc2VkLiAgICAgICAg ICAgICAgICAgICAgIHN0YXJ0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgQWNjb3VudGluZyBldmVudCByZXF1 ZXN0ICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJlY2VpdmVkLCBhbmQg c3VjY2Vzc2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgcHJvY2Vzc2VkLiAg ICAgICAgICAgICAgICAgICAgIGV2ZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgSW50ZXJpbSByZWNvcmQg cmVjZWl2ZWQsICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIGFuZCBzdWNj ZXNzZnVsbHkgcHJvY2Vzc2VkLiAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgQWNjb3Vu dGluZyBzdG9wIHJlcXVlc3QgICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAg IHJlY2VpdmVkLCBhbmQgc3VjY2Vzc2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAg ICAgcHJvY2Vzc2VkICAgICAgICAgICAgICAgICAgICAgIHN0b3AgYW5zd2VyDQoNCiAgICAgIElk bGUgICAgICBBY2NvdW50aW5nIHJlcXVlc3QgcmVjZWl2ZWQsICAgU2VuZCAgICAgICBJZGxlDQog ICAgICAgICAgICAgICAgbm8gc3BhY2UgbGVmdCB0byBzdG9yZSAgICAgICAgIGFjY291bnRpbmcN CiAgICAgICAgICAgICAgICByZWNvcmRzICAgICAgICAgICAgICAgICAgICAgICAgYW5zd2VyLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN1bHQtQ29k ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IE9VVF9P Rl8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU1BBQ0UN Cg== ------_=_NextPart_002_01C1D988.14C02180-- ------_=_NextPart_001_01C1D9B7.AF76B0FF-- From owner-aaa-wg@merit.edu Mon Apr 1 15:00:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12305 for ; Mon, 1 Apr 2002 15:00:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B25F91242; Mon, 1 Apr 2002 14:59:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BC189124D; Mon, 1 Apr 2002 14:59:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 893A891242 for ; Mon, 1 Apr 2002 14:59:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4187C5DE5C; Mon, 1 Apr 2002 14:59:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 7F8A55DE1F for ; Mon, 1 Apr 2002 14:59:26 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31Jxf516282 for ; Mon, 1 Apr 2002 22:59:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:59:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:59:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Date: Mon, 1 Apr 2002 22:59:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E530@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWcTyP3Clcq3ZuQnS36H+Z/IUP/ADQ6TxA From: To: , Cc: X-OriginalArrivalTime: 01 Apr 2002 19:59:25.0010 (UTC) FILETIME=[B90F1320:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12305 Hi all, My feeling that this is a possible regext. John > -----Original Message----- > From: ext David Frascone [mailto:dave@frascone.com] > Sent: 28 March, 2002 17:09 > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Cc: dave@frascone.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is > redundant > > > > > On Thursday, 28 Mar 2002, Ext-Venkata.Ghadiyaram@nokia.com wrote: > > Hi David, > > > > By "firewall involvemet" do you mean the firewall > translates the address. The address/addresses retrieved from > the transport layer are the addresses where the host can be > reached. If there are addresses using which a host cannot be > reached, why does one want to advertise them and why will be > the receiver interested in them. > > By firewall involvement, I mean that I have five load > balancing Diameter > servers behind a firewall. But, only one of the servers has > an IP address > that is reachable from the net for inbound connections. The firewall > blocks the rest. Since SYN's will be discarded by the > firewall, shouldn't > all five servers advertise the only routable address as their > Host-IP-Address? > > > > > In case of a multihomed host running SCTP, still all the > IPAddresses can be obtained from the SCTP association. > > Ok. What about TCP? Since TCP is a mandatory MUST, > Host-IP-Address seems > to have value. > > Since it has *some* value, why remove it. > > > In any case I do not see any reason for the IPAddress > information to be carried in the Diameter payload. > > I see reasons (mentioned above), so I am *against* this change. > > -- > David Frascone > > IBM: I Buy Macinstosh > From owner-aaa-wg@merit.edu Mon Apr 1 15:00:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12318 for ; Mon, 1 Apr 2002 15:00:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DB519124E; Mon, 1 Apr 2002 14:59:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F30D9124D; Mon, 1 Apr 2002 14:59:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D41CA91249 for ; Mon, 1 Apr 2002 14:59:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB79F5DE59; Mon, 1 Apr 2002 14:59:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id D3D7C5DE1F for ; Mon, 1 Apr 2002 14:59:31 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g31Jweu29414 for ; Mon, 1 Apr 2002 22:58:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Apr 2002 22:59:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 22:59:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Session-Server-Failover and STR Date: Mon, 1 Apr 2002 22:59:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E531@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Session-Server-Failover and STR Thread-Index: AcHZiBB8SQPUGaadRM+vbXMAl5/zOQALV8Pw From: To: , X-OriginalArrivalTime: 01 Apr 2002 19:59:26.0431 (UTC) FILETIME=[B9E7E6F0:01C1D9B7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12318 Hi Jari, As this is not contridictory, I think it is safer to leave it in - i.e. - be explicit. Unless it does some harm. I think we can just mark this as a reject. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 01 April, 2002 15:34 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [issue] Session-Server-Failover and STR > > > Submitter name: Jari Arkko > Submitter email address: jari.arkko@kolumbus.fi > Date first submitted: April 1, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 8.18 > Rationale/Explanation of issue: > > The ALLOW_SERVICE and TRY_AGAIN_ALLOW_SERVICE cases talk > about what to do after STR fails, and indicate that, if > the delivery of the STR fails, the session should be > terminated. > > Duh! Isn't the session terminated _anyway_ if we are > in the progress of sending STRs? > > But perhaps I'm missing something. > > > From owner-aaa-wg@merit.edu Mon Apr 1 16:25:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15581 for ; Mon, 1 Apr 2002 16:25:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F37789123B; Mon, 1 Apr 2002 16:25:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C98E59123E; Mon, 1 Apr 2002 16:25:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 762E39123B for ; Mon, 1 Apr 2002 16:25:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 508BA5DE66; Mon, 1 Apr 2002 16:25:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id BE4265DDEE for ; Mon, 1 Apr 2002 16:25:36 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g31LPTl01014; Mon, 1 Apr 2002 15:25:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g31LPTw26517; Mon, 1 Apr 2002 15:25:29 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23542; Mon, 1 Apr 2002 15:25:29 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA10935; Mon, 1 Apr 2002 15:25:28 -0600 (CST) Message-ID: <3CA8CF9C.FCE37531@ericsson.com> Date: Mon, 01 Apr 2002 13:22:36 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu, DSpence@Interlinknetworks.com Subject: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 Content-Type: multipart/alternative; boundary="------------C5993BF9046FDA85EC286670" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------C5993BF9046FDA85EC286670 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello David and All, I haven't seen any comments on this issue, so I'm not sure what people think about this. If we think it's useful, I could add something like the following: "7.5 Event-Timestamp AVP The The Event-Timestamp (AVP Code 55) is of type Unsigned32, and MAY be included in an Accounting-Request message to record the time that this event occurred on the mobility agent, in seconds since January 1, 1970 00:00 UTC." Comments please, Tony Issue 296: Possible new AVP for MobileIPv4 Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: MobileIPv4 Comment type: T Priority: 2 Section: Rationale/Explanation of issue: The following attribute is defined in RADIUS for use in accounting messages.It might be useful in the MobileIPv4 application. CODE NAME RFC --------- ------------------ ---- 55 Event-Timestamp 2869 Requested change: Consider adding this attribute to MobileIPv4 as a Diameter AVP. Note: This AVP will need to be defined in NASREQ for RADIUS compatibility. See issue TBA. --------------C5993BF9046FDA85EC286670 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello David and All,

I haven't seen any comments on this issue, so I'm not sure what people think about this.

If we think it's useful, I could add something like the following:

"7.5  Event-Timestamp AVP

The The Event-Timestamp (AVP Code 55) is of type Unsigned32, and MAY be included in an Accounting-Request message to record the time that this event occurred on the mobility agent, in seconds since January 1, 1970 00:00 UTC."

Comments please,

Tony
 
 
 

Issue 296: Possible new AVP for MobileIPv4
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: MobileIPv4
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:

The following attribute is defined in RADIUS for use in accounting
messages.It might be useful in the MobileIPv4 application.

CODE NAME RFC
--------- ------------------ ----
55 Event-Timestamp 2869

Requested change:

Consider adding this attribute to MobileIPv4 as a Diameter AVP.

Note: This AVP will need to be defined in NASREQ for RADIUS
compatibility. See issue TBA. --------------C5993BF9046FDA85EC286670-- From owner-aaa-wg@merit.edu Mon Apr 1 16:48:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16357 for ; Mon, 1 Apr 2002 16:48:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DADE49123E; Mon, 1 Apr 2002 16:48:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACDF99123F; Mon, 1 Apr 2002 16:48:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A499C9123E for ; Mon, 1 Apr 2002 16:48:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 84F755DE66; Mon, 1 Apr 2002 16:48:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 70DC05DD97 for ; Mon, 1 Apr 2002 16:48:25 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E500479; Mon, 1 Apr 2002 16:48:24 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , , Subject: RE: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 Date: Mon, 1 Apr 2002 16:47:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C1D99C.E475B750" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CA8CF9C.FCE37531@ericsson.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C1D99C.E475B750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tony, OK, I'll bite. It seems to me that allowing the Event-Timestamp AVP couldn't do any harm, and might be helpful. The virtue of the Event-Timestamp AVP is that mobility agents can send multiple accounting messages (start, interim, stop), all of which will reflect the same session start-time. That is, a MA can send an Accounting Start with an Event-Timestamp(value=T). N seconds later, the MA can send an Accounting Stop with an Event-Timestamp(value=T+N) and Acct-Session-Time(value=N). If you include your proposed text, you might consider changing the type from Unsigned32 to Time (an Unsigned32-derived type defined in the Base). Bob K. > From: owner-aaa-wg@merit.edu on behalf of Tony Johansson [tony.johansson@ericsson.com] > Sent: Monday, April 01, 2002 4:23 PM > To: aaa-wg@merit.edu; DSpence@Interlinknetworks.com > Subject: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 > Hello David and All, > I haven't seen any comments on this issue, so I'm not sure what people think about this. > > If we think it's useful, I could add something like the following: > > "7.5 Event-Timestamp AVP > > The The Event-Timestamp (AVP Code 55) is of type Unsigned32, and MAY be > included in an Accounting-Request message to record the time that this event > occurred on the mobility agent, in seconds since January 1, 1970 00:00 UTC." > > Comments please, > > Tony > > > Issue 296: Possible new AVP for MobileIPv4 > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: March 4, 2002 > Reference: > Document: MobileIPv4 > Comment type: T > Priority: 2 > Section: > Rationale/Explanation of issue: > > The following attribute is defined in RADIUS for use in accounting > messages.It might be useful in the MobileIPv4 application. > > CODE NAME RFC > --------- ------------------ ---- > 55 Event-Timestamp 2869 > > Requested change: > > Consider adding this attribute to MobileIPv4 as a Diameter AVP. > > Note: This AVP will need to be defined in NASREQ for RADIUS > compatibility. See issue TBA. > ------=_NextPart_000_001A_01C1D99C.E475B750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tony,
 
OK, I'll bite.  It seems = to me that=20 allowing the Event-Timestamp AVP couldn't
do any harm, and might be=20 helpful.  The virtue of the Event-Timestamp AVP is
that mobility = agents=20 can send multiple accounting messages (start, interim,
stop), all of = which=20 will reflect the same session start-time.  That is, a MA
can = send an=20 Accounting Start with an Event-Timestamp(value=3DT).  N = seconds
later, the=20 MA can send an Accounting Stop with an = Event-Timestamp(value=3DT+N)
and=20 Acct-Session-Time(value=3DN).
 
If you include your proposed = text, you=20 might consider changing the type
from Unsigned32 to Time (an=20 Unsigned32-derived type defined in the Base).
 
Bob K.

> From: owner-aaa-wg@merit.edu on = behalf of=20 Tony Johansson [tony.johansson@ericsson.com]
>=20 Sent: Monday, April 01, 2002 4:23 PM
> To: aaa-wg@merit.edu; DSpence@Interlinknetworks.c= om
>=20 Subject: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4
> = Hello=20 David and All,
> I haven't seen any comments on this issue, so = I'm not=20 sure what people think about this.
>
> If we think it's = useful, I=20 could add something like the following:
>
> "7.5 =20 Event-Timestamp AVP
>
> The The Event-Timestamp (AVP Code = 55) is=20 of type Unsigned32, and MAY be
> included in an Accounting-Request = message=20 to record the time that this event
> occurred on the mobility = agent, in=20 seconds since January 1, 1970 00:00 UTC."
>
> Comments = please,=20
>
> Tony
>  
>
> Issue 296: = Possible new AVP for MobileIPv4
> Submitter name: David Spence =
>=20 Submitter email address: DSpence@Interlinknetworks.c= om=20
> Date first submitted: March 4, 2002
> Reference: =
>=20 Document: MobileIPv4
> Comment type: T
> Priority: 2 =
>=20 Section:
> Rationale/Explanation of issue:
>
> The=20 following attribute is defined in RADIUS for use in accounting
>=20 messages.It might be useful in the MobileIPv4 application.
> =
>=20 CODE NAME RFC
> --------- ------------------ ----
> 55=20 Event-Timestamp 2869
>
> Requested change:
> =
>=20 Consider adding this attribute to MobileIPv4 as a Diameter AVP.
> =
> Note: This AVP will need to be defined in NASREQ for RADIUS =
>=20 compatibility. See issue TBA.
>
------=_NextPart_000_001A_01C1D99C.E475B750-- From owner-aaa-wg@merit.edu Mon Apr 1 17:18:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16952 for ; Mon, 1 Apr 2002 17:18:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4970D91241; Mon, 1 Apr 2002 17:18:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1740C91243; Mon, 1 Apr 2002 17:18:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAE9C91241 for ; Mon, 1 Apr 2002 17:18:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id C69B95DDDD; Mon, 1 Apr 2002 17:18:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 84B215DD97 for ; Mon, 1 Apr 2002 17:18:44 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 446DC79; Mon, 1 Apr 2002 17:18:44 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , "aaa-wg" Subject: RE: [AAA-WG]: Issue #299 and #301 Date: Mon, 1 Apr 2002 17:17:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C9ED1FB.C4767485@ericsson.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Tony, At this time, I have nothing more to offer in terms of an issue#299 solution, but I have another related snag, the solution to which can be part of the issue#299 solution. This problem isn't with the MN-handoff, but is with the initial AMR for a mobile session, and has to do with the problem of mapping the HA's IP address to the HA's identity. Here we go: Suppose a MN initially hooks up with an FA in some foreign network, and the MN knows his HA's IP address in the home network. So the AMR carries a MIP-Home-Agent-Address AVP, and is routed to some AAAH in the home network. When the AAAH receives this AMR, the AAAH will want to send an HAR to the HA, and will need the HA's identity for the HAR's Destination-Host AVP. If the targeted HA is a direct peer of the AAAH, then this is no problem. The AAAH just looks into his peer table for a peer with an IP address matching the value of the AMR's MIP-Home-Agent-Address AVP. But if the HA is not a direct peer of the AAAH, then the AAAH has to somehow map the HA's IP address to the HA's identity. Three ideas pop into mind: 1. Require that all home-network HAs be direct peers of all the home-network AAAHs. or 2. Require an MN who remembers his HA's IP address between sessions to also remember the HA's identity between sessions, and send both of these HA identification items in the Registration Request. The FA would extract both of these items from the Registration Request, and send them as Diameter AVPs in the initial AMR. or 3. Indicate that the AAAHs must have some mechanism, not specified in the protocol, of mapping the home-network's HA IP addresses into DiameterIdentities. Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Tony Johansson > Sent: Monday, March 25, 2002 2:30 AM > To: aaa-wg > Cc: Bob Kopacz; Fredrik Johansson; Johan Johansson; David Spence; Pat R. > Calhoun > Subject: [AAA-WG]: Issue #299 and #301 > > > All, > > During, the AAA working group meeting at IETF53 I presented the > issues #299 and > #301 and two alternative ways in which we could workout a solution to the open > issues - see below: > > Alt1: Clarifications / new requirements without any new dependencies to MIP. > ------------------------------------------------------------------------------ > > AAAH > - Require that each subdomain of a realm is authorized/authenticated > by exactly > one AAAH. So while a home network may have multiple AAAH's, each > subdomain will > have exactly one AAAH. > > - Or, require that, if the home realm has multiple AAA servers to > which the same > user can be routed to, then there MUST be a synchronization > mechanism between the AAAH servers. However, the specific synchronization > mechanism is beyond the scope of this spec. > > AAAF > - How to map HA IP address to HA FQDN is still open. Reverse DNS look > up is not > at all a straightforward solution for this… > > > Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. > ----------------------------------------------------------------------------- > > AAAH > - Require that the MN support the GNAIE draft, updated to include the > definition > of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI > would be included to guarantee that a registered user always ends up > in the same > initial AAAH. > > AAAF > - The mapping of the HA IP address and HA FQDN, Host and realm would be > automatically solved, since this would be included in the MIP RegReq as well. > > There was a very clear and strong consensus that alternative 2 would be by far > the best solution. However, this means more work and dependencies > to the MIP working group and the goal is set to have the Diameter MIPv4 appl. > draft in working group last call by the April 2nd. Looking at the > GNAIE draft, I done see that much work needs to be done to make it fulfill our > needs, so to me it could easily be done in time, but the big > question is how quickly could it be pushed through the MIP working > group and go > to last call? I have sent the question MIP wg and I hope to soon get answer > back. > > Regards, > > Tony > > > > From owner-aaa-wg@merit.edu Mon Apr 1 17:22:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17168 for ; Mon, 1 Apr 2002 17:22:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 81A9D91243; Mon, 1 Apr 2002 17:21:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F70091244; Mon, 1 Apr 2002 17:21:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3928891243 for ; Mon, 1 Apr 2002 17:21:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A74C5DDDD; Mon, 1 Apr 2002 17:21:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id DDC1B5DD97 for ; Mon, 1 Apr 2002 17:21:54 -0500 (EST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel13.hp.com (Postfix) with ESMTP id 776EC4006A1 for ; Mon, 1 Apr 2002 14:21:44 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA08210; Mon, 1 Apr 2002 14:22:40 -0800 (PST) Date: Mon, 1 Apr 2002 14:22:40 -0800 (PST) From: Joe Lau Message-Id: <200204012222.OAA08210@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: AAA NAI for Mobile IPv4 Extension draft In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E527@esebe004.NOE.Nokia.com> Cc: jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Section 1 of the AAA NAI for Mobile IPv4 Extension draft says: To solve this the home agent MUST include the AAAH NAI in the registration reply message, which the mobile node then MUST include in every subsequent registration request sent to a foreign agent when change point of attachement. It is clear that the MN must include the AAA NAI in every subsequent registration request. But it is not clear whether the Home Agent must incude the AAA NAI in _every_ registration reply message. My own interpretation would be the Home Agent must inlcude the AAAH NAI in the _initial_ registration reply message (e.g. the one that is delivered via the HAA message). The MN then will cache the AAAH NAI and use it for every subsequent registraton request. Is this also what the author has in mind? Thanks for the clarification. Regards, Joe lau From owner-aaa-wg@merit.edu Mon Apr 1 17:24:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17196 for ; Mon, 1 Apr 2002 17:24:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A96C691244; Mon, 1 Apr 2002 17:24:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 752A991245; Mon, 1 Apr 2002 17:24:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4279791244 for ; Mon, 1 Apr 2002 17:24:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 237515DDDD; Mon, 1 Apr 2002 17:24:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 92E965DD97 for ; Mon, 1 Apr 2002 17:24:10 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g31MO9l24799; Mon, 1 Apr 2002 16:24:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g31MO9V13159; Mon, 1 Apr 2002 16:24:09 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA28951; Mon, 1 Apr 2002 16:24:08 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA11984; Mon, 1 Apr 2002 16:24:07 -0600 (CST) Message-ID: <3CA8DD21.8DD8D31C@ericsson.com> Date: Mon, 01 Apr 2002 14:21:15 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sivasundar_ramamurthy@hp.com Cc: sramam@cup.hp.com, aaa-wg@merit.edu Subject: [AAA-WG]: Issue 317:FA-HA Key Content-Type: multipart/alternative; boundary="------------8874FDE44E35B1FCB8757932" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------8874FDE44E35B1FCB8757932 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Siva and All, How about the following clarification: change: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing keys with the HA, it MAY set the FA-HA-Key-Request flag". to: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing FA-HA key with the HA, the FA MAY set the FA-HA-Key-Request flag" I hope this makes it more explicit. And to your question below; - "In other words, is the FA-HA key session specific or not?" I guess you can use the same FA-HA key for multiple session, but I would say this is implementation specific if you use one FA-HA key per session or not, and should NOT be stated in the spec. Furthermore, since we only have one key lifetime per session, you better be careful if you use the same FA-HA key for multiple session.... /Tony Issue 317:FA-HA Key Submitter Name: Siva Ramamurthy Submitter email address: sivasundar_ramamurthy@hp.com Date first submitter: 3/27/2002 Document: Mobile IP Comment Type: T Priority: 1 Section: 4.5 Explanation of Issue: Section 4.5 has text that says: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing keys with the HA, it MAY set the FA-HA-Key-Request flag". the co-existance of the phrases "any existing keys" and "AAA session keys" is confusing! Is the FA-HA key to be used only for the session from which it was obtained, or can it be used with any other sessions that require communciation between this FA and HA? In other words, is the FA-HA key session specific or not? Requested Change: Please clarify, since different implementations at the FA and HA can lead to needless FOR_HOME authentication failures. --------------8874FDE44E35B1FCB8757932 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Siva and All,

How about the following clarification:

change:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing keys with the HA, it MAY set the
FA-HA-Key-Request flag".

to:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing FA-HA key with the HA, the FA MAY set the
FA-HA-Key-Request flag"

I hope this makes it more explicit.
 

And to your question below;  - "In other words, is the FA-HA key session specific or not?"

I guess you can use the same FA-HA key for multiple session, but I would say this is implementation specific if you use one FA-HA key per session or not, and should NOT be stated in the spec. Furthermore, since we only have one key lifetime per session, you better be careful if you use the same FA-HA key for multiple session....
 

/Tony
 

Issue 317:FA-HA Key
Submitter Name: Siva Ramamurthy
Submitter email address: sivasundar_ramamurthy@hp.com
Date first submitter: 3/27/2002
Document: Mobile IP
Comment Type: T
Priority: 1
Section: 4.5

Explanation of Issue:

Section 4.5 has text that says:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing keys with the HA, it MAY set the
FA-HA-Key-Request flag".

the co-existance of the phrases "any existing keys" and "AAA session
keys" is confusing! Is the FA-HA key to be used only for the session
from which it was obtained, or can it be used with any other sessions
that require communciation between this FA and HA? In other words, is
the FA-HA key session specific or not?

Requested Change:
Please clarify, since different implementations at the FA and HA can
lead to needless FOR_HOME authentication failures. --------------8874FDE44E35B1FCB8757932-- From owner-aaa-wg@merit.edu Mon Apr 1 17:36:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17650 for ; Mon, 1 Apr 2002 17:36:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA49491245; Mon, 1 Apr 2002 17:36:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B808191246; Mon, 1 Apr 2002 17:36:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B73591245 for ; Mon, 1 Apr 2002 17:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 691855DE60; Mon, 1 Apr 2002 17:36:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id D5FD75DDDD for ; Mon, 1 Apr 2002 17:36:39 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g31Madl29834; Mon, 1 Apr 2002 16:36:39 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g31Macw09122; Mon, 1 Apr 2002 16:36:38 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA00032; Mon, 1 Apr 2002 16:36:38 -0600 (CST) Received: from ericberk107 ([138.85.159.127]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id QAA12238; Mon, 1 Apr 2002 16:36:37 -0600 (CST) Message-ID: <014b01c1d9cd$af7de0f0$7f9f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Joe Lau" , References: <200204012222.OAA08210@strtio1.cup.hp.com> Subject: Re: [AAA-WG]: Re: AAA NAI for Mobile IPv4 Extension draft Date: Mon, 1 Apr 2002 14:36:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe, Section 5, paragraph 2 states: "The home agent MUST provide this in every registratin reply if using the AAA server for authentication." So, every time the HA creates and sends a MIP reg reply and returns it to a AAA server through a HAA message, the AAA NAI must be present. -Kevin ----- Original Message ----- From: "Joe Lau" To: Cc: Sent: Monday, April 01, 2002 2:22 PM Subject: [AAA-WG]: Re: AAA NAI for Mobile IPv4 Extension draft > This message uses a character set that is not supported by the Internet > Service. To view the original message content, open the attached > message. If the text doesn't display correctly, save the attachment to > disk, and then open it using a viewer that can display the original > character set. <> > From owner-aaa-wg@merit.edu Mon Apr 1 17:49:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18010 for ; Mon, 1 Apr 2002 17:49:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34A4891246; Mon, 1 Apr 2002 17:49:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 047C791247; Mon, 1 Apr 2002 17:49:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E663991246 for ; Mon, 1 Apr 2002 17:49:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id C3BB15DDEE; Mon, 1 Apr 2002 17:49:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id A58875DDDD for ; Mon, 1 Apr 2002 17:49:05 -0500 (EST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 4368FC00484; Mon, 1 Apr 2002 14:49:05 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA08282; Mon, 1 Apr 2002 14:50:01 -0800 (PST) Date: Mon, 1 Apr 2002 14:50:01 -0800 (PST) From: Joe Lau Message-Id: <200204012250.OAA08282@strtio1.cup.hp.com> To: kevin.purser@ericsson.com Subject: Re: [AAA-WG]: Re: AAA NAI for Mobile IPv4 Extension draft In-Reply-To: <014b01c1d9cd$af7de0f0$7f9f558a@ew.us.am.ericsson.se> Cc: aaa-wg@merit.edu, jlau@strtio1.cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, > Section 5, paragraph 2 states: > > "The home agent MUST provide this in every registratin reply if using > the AAA server for authentication." > > So, every time the HA creates and sends a MIP reg reply and returns it to a > AAA server through a HAA message, the AAA NAI must be present. Ahh, I wasn't clear in my stating my own interpretation. What I meant was that the HA does not need to include the AAA NAI in _every_ registration reply message it sends back to the MN (only on the reply that is delivered via the HAA message). I guess I didn't read section 5 carefully. Thanks for the clarification. Regards, Joe Lau > -Kevin > > ----- Original Message ----- > From: "Joe Lau" > To: > Cc: > Sent: Monday, April 01, 2002 2:22 PM > Subject: [AAA-WG]: Re: AAA NAI for Mobile IPv4 Extension draft > > > > This message uses a character set that is not supported by the Internet > > Service. To view the original message content, open the attached > > message. If the text doesn't display correctly, save the attachment to > > disk, and then open it using a viewer that can display the original > > character set. <> > > > > From owner-aaa-wg@merit.edu Mon Apr 1 17:49:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18036 for ; Mon, 1 Apr 2002 17:49:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E88691247; Mon, 1 Apr 2002 17:49:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D97E91248; Mon, 1 Apr 2002 17:49:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B73FC91247 for ; Mon, 1 Apr 2002 17:49:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99B935DE60; Mon, 1 Apr 2002 17:49:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 78C205DDDD for ; Mon, 1 Apr 2002 17:49:24 -0500 (EST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel13.hp.com (Postfix) with ESMTP id 0AE79400255; Mon, 1 Apr 2002 14:49:22 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA08296; Mon, 1 Apr 2002 14:50:18 -0800 (PST) Date: Mon, 1 Apr 2002 14:50:18 -0800 (PST) From: Joe Lau Message-Id: <200204012250.OAA08296@strtio1.cup.hp.com> To: tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: <3CA8DD21.8DD8D31C@ericsson.com> Cc: aaa-wg@merit.edu, sivasundar_ramamurthy@hp.com, sramam@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, > And to your question below; - "In other words, is the FA-HA key session > specific or not?" > > I guess you can use the same FA-HA key for multiple session, but I would > say this is implementation specific if you use one FA-HA key per session > or not, and should NOT be stated in the spec. If we don't state whethter the FA-HA key is session specific or not, won't there may be potential interoperability problem between FA (from vendor A) and HA (from vendor B)? Regards, Joe Lau From owner-aaa-wg@merit.edu Mon Apr 1 18:32:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18924 for ; Mon, 1 Apr 2002 18:32:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6AF8A91248; Mon, 1 Apr 2002 18:32:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3065791249; Mon, 1 Apr 2002 18:32:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACFE391248 for ; Mon, 1 Apr 2002 18:31:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 732F95DDDD; Mon, 1 Apr 2002 18:31:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id C9AFC5DDA5 for ; Mon, 1 Apr 2002 18:31:35 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g31NVZl21232 for ; Mon, 1 Apr 2002 17:31:35 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g31NVYw17431 for ; Mon, 1 Apr 2002 17:31:35 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA04935 for ; Mon, 1 Apr 2002 17:31:34 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA13185 for ; Mon, 1 Apr 2002 17:31:33 -0600 (CST) Message-ID: <3CA8ED29.353E921D@ericsson.com> Date: Mon, 01 Apr 2002 15:28:42 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Fwd: Issue #299 and #301] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm sorry if you receive this twice...... /Tony -------- Original Message -------- Subject: Issue #299 and #301 Date: Mon, 01 Apr 2002 11:53:07 -0800 From: Tony Johansson To: aaa-wg@merit.edu All, I have worked on new proposed text for issue 299 and 301, see below, based on the solution we agree upon at the IETF 53. Part of this solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines the needed AAAH NAI and the HA NAI, please see http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt. The draft have been submitted to the mobileip wg and will go to wg final call if no major comments/issues are found on the mobileip wg list. I hope this solves the issue 299 and 301, however I need help to understand how I should deal the newly submitted issue #321 regarding CMS. Is it good enough to just move the CMS ref to informative? Comments please. /Tony Added to to section 1.0: "1.0 Introduction ... Furthermore, the nature of mobile IP also means that the mobile node will do handoffs between different foreign agents and to guarantee that a registered user always ends up in the same initial AAAH the Mobile Node MUST always include the home NAI and the AAAH NAI [AAANAI]. ... " I've made changes here and there in section 1.2, 1.3 and 1.4, so here is the whole text... " 1.2 Inter-Realm Mobile IP When a Mobile Node node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA- Mobile-Node-Request (AMR) message, which includes the AVPs defined in section 2.1. The Home Address, Home Agent, Mobile Node NAI and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF. Visited Realm Home Realm +--------+ +--------+ |abc.com | AMR/AMA |xyz.com | | AAAF |<------------------->| AAAH | +->| server | server-server | server | | +--------+ communication +--------+ | ^ ^ | AMR/AMA | client-server | HAR/HAA | | communication | v v v +---------+ +---------+ +---------+ | Foreign | | Foreign | | Home | | Agent | | Agent | | Agent | +---------+ +---------+ +---------+ ^ | Mobile IP | v +--------+ | Mobile | | Node | mn@xyz.com +--------+ Figure 1: Inter-Realm Mobility Upon receiving the AMR, the AAAF follows the procedures outlined in [DIAMBASE] to determine whether the AMR should be processed locally, or if it should be forwarded to another Diameter server, known as the AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node (mn@xyz.com) requests service from a foreign provider (abc.com). The request received by the AAAF is forwarded to xyz.com's AAAH server. Figure 2 shows the message flows involved when the foreign agent invokes the AAA infrastructure to request that a mobile node be authenticated and authorized. Note that it is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile, but rather only when the prior authorization from the AAAH expires. The expiration time of the authorization is communicated through the Authorization-Lifetime AVP in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. Mobile Node Foreign Agent AAAF AAAH Home Agent ----------- ------------- ------------ ---------- ---------- Advertisement & <--------- Challenge Reg-Req&MN-AAA ----> AMR------------> Session-Id = foo AMR------------> Session-Id = foo HAR-----------> Session-Id = bar <----------HAA Session-Id = bar <-----------AMA Session-Id = foo <------------AMA Session-Id = foo <-------Reg-Reply Figure 2: Mobile IP/Diameter Message Exchange The foreign agent (as shown in Figure 2) MAY provide a challenge, which gives it direct control over the replay protection in the Mobile IP registration process, as described in [MIPCHAL]. The mobile node includes the Challenge and MN-AAA authentication extension to enable authorization by AAAH. If the authentication data supplied in the MN-AAA extension is invalid, AAAH returns the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED. A mobile node, which has been previously authenticated andauthorized, MUST always include the assigned home agent in the HA-NAI and the authorizing Home AAA server in the AAAH-NAI in the registration request message [AAANAI] sent to the FA, every time the Mobile Node needs to re-authenticating. So, in the event that the AMR generated by the FA is for a session that has was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- Host AVP the identity of the assigned HA found in the HA-NAI. If the mobile node was successfully authenticated, the AAAH checks if the Home Agent was located in the foreign realm, by checking the MIP- Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If home agent is located in the foreign realm, then AAAH sends an HAR message to the home agent, which contains a MIP-Reg-Request AVP. If the home agent was not located in the foreign realm, the AAAH checks for the MIP-Home-Agent-Address AVP and if present the MIP- Home-Agent-Host AVP. If one was specified, the AAAH checks that the address is that of a known home agent and that the Mobile Node is allowed to request this particular home agent, and that the home agent's identity is included in the MIP-Home-Agent-Host AVP. If no home agent was specified, and if the MIP-Feature-Vector has the Home- Agent-Requested flag set, and if allowed by policy in the home realm, the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This can be done in a variety of ways, including using a load balancing algorithm in order to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents is outside the scope of this specification. The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a home address for the mobile node, while the Home Agent MUST support home address allocation. In the event the AAAH handles address allocation, it includes it in a MIP-Mobile-Node- Address AVP within the HAR. The absence of this AVP informs the Home Agent to perform the allocation. During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see Figure 2). If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR. A mobile node's session is identified via its identity in the User- Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [DIAMBASE], to be used unmodified with this application. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the one towards the home agent (see figure 3). STR, Session-Id = foo STR, Session-Id = bar ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> STA, Session-Id = foo STA, Session-Id = bar Figure 3: Session Termination and Session Identifiers Upon receipt of the HAR, the home agent first processes the Diameter message. The home agent processes the MIP-Reg-Request AVP and creates the Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. In the creation of the Registration Reply the Home Agent must include the HA NAI and the AAAH NAI, which will be created from the Originating-Host AVP and Originating-Realm AVP of the HAR. If a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and within the MIP-Mobile- Node-Address AVP. The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA returned to the AAAH. Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, includes the Accounting-Multi-Session-Id that was present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- Address AVPs in the AMA message, enabling appropriate firewall controls for the penetration of tunneled traffic between the Home Agent and the Mobile Node. The AAAF is responsible for ensuring that the AMA message is properly forwarded to the correct foreign agent. 1.3 Support for Mobile IP Handoffs Given the nature of Mobile IP, a mobile node MAY receive service from many foreign agents during a period of time. However, the home realm should not view these handoffs as different sessions, since this could affect billing systems. Furthermore, many foreign agents do not communicate, which makes it quite difficult for AAA information to be exchanged between these entities. Therefore, it MUST be assumed that a foreign agent is not aware that a registration request from a mobile node has been previously authorized. The first registration request from a mobile node will therefore cause an AMR to be sent to its AAAF. The AMR will include a new session identifier, and MAY even be sent to a different AAAF in the visited network. Since the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier. It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, the home agent MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Accounting-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. This Accounting-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Accounting-Multi-Session-Id in the accounting messages. ACR, Session-Id = foo ACR, Session-Id = bar Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> ACA, Session-Id = foo ACA, Session-Id = bar Figure 4: Accounting messages w/ Mobile IP Application 1.4 Allocation of Home Agent in Foreign Network The Diameter Mobile IP application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home- Agent- Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to zero. When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- Agent-Host AVP contains the identity of the home agent that would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. In the event that the mobile node has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will in create the AMR including the MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a Home Agent for the mobile node, i.e. the Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or the AMR indicates that the AAAF has offered a previously allocated Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- Network is set in the MIP-Feature-Vector AVP, then the AAAH must decide whether its local policy would allow the user to have a Home Agent in the foreign network or to keep the Home Agent in the foreign network. If so, and after checking authorization from the data in the AMR message, the AAAH sends the HAR message to Home Agent byincluding the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if the HA has been previously allocated and authorized by the AAAH. If the HA has not been previously allocated by the foreign domain, the HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. The HAR sent by the AAAH back to the foreign realm with the Destination-Host AVP set to the home agents identity, may not necessarily be received by the same AAAF, which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, the new AAAF will use the MIP-Originating- Foreign-AAA AVP for policy decisions, such as determining if the FA- HA Key should be encrypted or not. If on the other hand, the AAAH local policy determines that the MN-HA Key and the MN-FA Key must be encrypted and no security association is known to the home agent, the AAAH SHOULD send the HAR to the originating AAAF by including the Destination-Host AVP set to the value found in the AMR's MIP- Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR. Visited Home Realm Realm +--------+ ------- AMR -------> +--------+ | AAAF | <------ HAR -------- | AAAH | | | | | +--->| server | ------- HAA -------> | server | | +--------+ <------ AMA -------- +--------+ | ^ | | | | HAR/HAA | AMR | | AMA v | v +---------+ +---------+ | Home | | Foreign | | Agent | | Agent | +---------+ +---------+ ^ +--------+ | | Mobile |<----------+ | Node | Mobile IP +--------+ Figure 5: Home Agent allocated in Visited Realm Upon receipt of a HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed, and issued to the AAAF, and finally to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP- Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. Mobile Node Foreign Agent Home Agent AAAF AAAH ----------- ------------- ------------- ---------- ---------- <----Challenge---- Reg-Req (Response)-> ------------AMR-------------> -----AMR----> <----HAR----- <-----HAR------ ------HAA------> -----HAA----> <----AMA----- <-------------AMA------------ <---Reg-Reply---- Figure 6: Mobile IP/Diameter Message Exchange If the Mobile Node moves to another Foreign Network, it MAY either request to keep the same Home Agent within the old foreign network, or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the mobile node will have to interact with two AAAFs. Figure 7 shows the message flows for a Mobile Node requesting to keep the Home Agent assigned in Foreign network 1 when it moves to foreign network 2. Upon reception of the AMR in Foreign network 2, the AAAF follows the procedures described earlier and forwards AMR to the Mobile Node's home network, i.e. its AAAH. If the Mobile Node was successfully authenticated, the AAAH checks the identity of the foreign and home agent to determine whether the user is in a third realm. If this is the case, the AAAH must check whether the mobile is still permitted to use the previously assigned Home Agent. +---------------+ +---------------+ +-------------+ |Foreign net 2 | |Foreign net 1 | |Home network | | | | | | | Mobile Node | FA AAAF | | HA AAAF | | AAAH | ----------- | ---- ---- | | ---- ------ | | ------ | +---------------+ +---------------+ +-------------+ <----Challenge---- Reg-Req (Response)-> ---AMR---> ----------------AMR---------------> <-----HAR----- <---HAR---- ----HAA---> ------HAA----> <---------------AMA---------------- <--AMA---- <----Reg-Reply----- Figure 7: Request to access Home Agent from new Foreign Network If the mobile node is allowed to keep the home agent the AAAH then sends a HAR, which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP and the MIP- Home-Agent-Address AVP with home agent address, as well as any optional KDC session keys, to the AAAF in foreign network 1. Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA AVP from AMR and include it in the HAR when a third foreign domain is involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not. Upon reception the AAAF in foreign network 1 will forward the HAR to the Home Agent if its local policy allows such service. If the AAAF does not permit such service, it MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If the AAAH local policy determines that the MN-HA Key must be encrypted and no security association is known to the home agent, the AAAH MUST send the HAR to the AAAF in foreign network 1, which originally assigned the HA in foreign network 1, by including its identity in the Destination-Host AVP. When the AAAF receives a HAA, the AAAF will forward the HAA back to the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an AMA to the AAAF in foreign network 2. If the old Foreign Network does not permit the use of its Home Agent when the Mobile Node moves to a new foreign network, the AAAH or AAAF MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile Node with an appropriate error. The Mobile Node MAY attempt to request that a new Home Agent and Address be allocated. When the AAAH transmits such an error, it MUST issue a Diameter Abort-Session- Request message to the Home Agent to enable it to release any resources. " Added to section 2.1 AA-Mobile-Node-Request: "2.1 AA-Mobile-Node-Request The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field set to 260 and the 'R' bit set in the Command Flags field, is sent by an attendant, acting as a Diameter client, to a server in order to request the authentication and authorization of a Mobile Node. The Foreign Agent (or Home Agent in the case of a co-located Mobile Node) uses information found in the Registration Request to construct the following AVPs that are to be included as part of the AMR: ... home agent NAI (MIP-Home-Agent-Host AVP) home AAA server NAI (Destination-Host AVP [DIAMBASE]) ... If the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home- Agent-Host AVP and the Destination-Host AVP in the AMR. ..." Added to section 4.0: " MIP-Home-Agent 348 4.12 Grouped | M | P | | V | Y | Host | | | | | | " Added a new grouped AVP: "4.12 MIP-Home-Agent-Host AVP The MIP-Home-Agent-Host AVP (AVP Code TBD)if of type Grouped, and contains the identity of the assigned Home Agent. If present in the AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. MIP-Home-Agent-Host ::= < AVP Header: 348 > { Destination-Realm } { Destination-Host } * [ AVP ] " Added new text to section 5.3 : " 5.3 Distributing the Mobile-Home Session Key ... If the home agent is in the home realm, then AAAH can directly encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include that AVP in the HAR message for delivery to the home agent. If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent. If the session key needs to be encrypted the AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data AVP using the security association with the home agent or with the AAAF associated with the home agent. If no security association is known the home agent, the AAAH will check if a security association can be established using DSA messages defined in the CMS application [CMS] with the originating host found in the MIP-Originating-Foreign- AAA AVP and if the DSA establishment is successful, the AAAH will encrypt the MIP-HA-to-MN Key AVP with the established security association. On the other hand, if no security association exists and the DSA establishment fails, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. ... " From owner-aaa-wg@merit.edu Mon Apr 1 18:38:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19064 for ; Mon, 1 Apr 2002 18:38:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B325891249; Mon, 1 Apr 2002 18:38:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84F469124A; Mon, 1 Apr 2002 18:38:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4619391249 for ; Mon, 1 Apr 2002 18:38:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B6D85DDEE; Mon, 1 Apr 2002 18:38:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id ECD435DDDD for ; Mon, 1 Apr 2002 18:38:32 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g31NcWi06408; Mon, 1 Apr 2002 17:38:32 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g31NcWV29221; Mon, 1 Apr 2002 17:38:32 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA05544; Mon, 1 Apr 2002 17:38:31 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA13296; Mon, 1 Apr 2002 17:38:30 -0600 (CST) Message-ID: <3CA8EECB.BA38A8C@ericsson.com> Date: Mon, 01 Apr 2002 15:35:39 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Issue #299 and #301 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Bob, Please have a look at the proposed text that I just sent out (which for some reason got lost the first time I tried earlier today :( /Tony Bob Kopacz wrote: > Hi Tony, > > At this time, I have nothing more to offer in terms of an issue#299 > solution, but I have another related snag, the solution to which can be > part of the issue#299 solution. > > This problem isn't with the MN-handoff, but is with the initial AMR for > a mobile session, and has to do with the problem of mapping the HA's IP > address to the HA's identity. > > Here we go: > > Suppose a MN initially hooks up with an FA in some foreign network, and > the MN knows his HA's IP address in the home network. So the AMR > carries a MIP-Home-Agent-Address AVP, and is routed to some AAAH in the > home network. > > When the AAAH receives this AMR, the AAAH will want to send an HAR to > the HA, and will need the HA's identity for the HAR's Destination-Host > AVP. > > If the targeted HA is a direct peer of the AAAH, then this is no problem. > The AAAH just looks into his peer table for a peer with an IP address > matching the value of the AMR's MIP-Home-Agent-Address AVP. > > But if the HA is not a direct peer of the AAAH, then the AAAH has to > somehow map the HA's IP address to the HA's identity. > > Three ideas pop into mind: > > 1. Require that all home-network HAs be direct peers of all the > home-network AAAHs. > > or > > 2. Require an MN who remembers his HA's IP address between sessions to > also remember the HA's identity between sessions, and send both of these > HA identification items in the Registration Request. The FA would > extract both of these items from the Registration Request, and send > them as Diameter AVPs in the initial AMR. > > or > > 3. Indicate that the AAAHs must have some mechanism, not specified in > the protocol, of mapping the home-network's HA IP addresses into > DiameterIdentities. > > Bob K. > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Tony Johansson > > Sent: Monday, March 25, 2002 2:30 AM > > To: aaa-wg > > Cc: Bob Kopacz; Fredrik Johansson; Johan Johansson; David Spence; Pat R. > > Calhoun > > Subject: [AAA-WG]: Issue #299 and #301 > > > > > > All, > > > > During, the AAA working group meeting at IETF53 I presented the > > issues #299 and > > #301 and two alternative ways in which we could workout a solution to the open > > issues - see below: > > > > Alt1: Clarifications / new requirements without any new dependencies to MIP. > > ------------------------------------------------------------------------------ > > > > AAAH > > - Require that each subdomain of a realm is authorized/authenticated > > by exactly > > one AAAH. So while a home network may have multiple AAAH's, each > > subdomain will > > have exactly one AAAH. > > > > - Or, require that, if the home realm has multiple AAA servers to > > which the same > > user can be routed to, then there MUST be a synchronization > > mechanism between the AAAH servers. However, the specific synchronization > > mechanism is beyond the scope of this spec. > > > > AAAF > > - How to map HA IP address to HA FQDN is still open. Reverse DNS look > > up is not > > at all a straightforward solution for this… > > > > > > Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. > > ----------------------------------------------------------------------------- > > > > AAAH > > - Require that the MN support the GNAIE draft, updated to include the > > definition > > of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI > > would be included to guarantee that a registered user always ends up > > in the same > > initial AAAH. > > > > AAAF > > - The mapping of the HA IP address and HA FQDN, Host and realm would be > > automatically solved, since this would be included in the MIP RegReq as well. > > > > There was a very clear and strong consensus that alternative 2 would be by far > > the best solution. However, this means more work and dependencies > > to the MIP working group and the goal is set to have the Diameter MIPv4 appl. > > draft in working group last call by the April 2nd. Looking at the > > GNAIE draft, I done see that much work needs to be done to make it fulfill our > > needs, so to me it could easily be done in time, but the big > > question is how quickly could it be pushed through the MIP working > > group and go > > to last call? I have sent the question MIP wg and I hope to soon get answer > > back. > > > > Regards, > > > > Tony > > > > > > > > From owner-aaa-wg@merit.edu Mon Apr 1 18:57:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19451 for ; Mon, 1 Apr 2002 18:57:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E23669124A; Mon, 1 Apr 2002 18:57:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF559124B; Mon, 1 Apr 2002 18:57:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 856A19124A for ; Mon, 1 Apr 2002 18:57:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BE855DDDD; Mon, 1 Apr 2002 18:57:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 21EB85DDD9 for ; Mon, 1 Apr 2002 18:57:31 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g31NvPg08104; Mon, 1 Apr 2002 18:57:25 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA18248; Mon, 1 Apr 2002 17:57:25 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g31NvON29913; Mon, 1 Apr 2002 17:57:24 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.62436.349086.94506@nwsgpc.ih.lucent.com> Date: Mon, 1 Apr 2002 17:57:24 -0600 (CST) From: Pete McCann To: john.loughney@nokia.com Cc: , Subject: RE: [AAA-WG]: Re: Bug in Acct state machine In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E52E@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E52E@esebe004.NOE.Nokia.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, John, See my latest e-mail to the list on defining "Failure to send" and collapsing 2 actions into one; I didn't propose specific text, but Jari seemed to be making quick edits so I was hoping he could turn it around. Are we delaying the last call? I can have some text to you by tomorrow at noon CST unless Jari can do it sooner. -Pete john.loughney@nokia.com writes: > Hi all, > > I've made the changes according to this text, please let me know if anything > still needs some updating. > > John From owner-aaa-wg@merit.edu Mon Apr 1 19:06:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19757 for ; Mon, 1 Apr 2002 19:06:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2AE569124B; Mon, 1 Apr 2002 19:06:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAC849124C; Mon, 1 Apr 2002 19:06:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1FFF9124B for ; Mon, 1 Apr 2002 19:06:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F0B35DDD9; Mon, 1 Apr 2002 19:06:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 37B1D5DDC2 for ; Mon, 1 Apr 2002 19:06:19 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3206Il02279; Mon, 1 Apr 2002 18:06:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3206Iw21947; Mon, 1 Apr 2002 18:06:18 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA07885; Mon, 1 Apr 2002 18:06:17 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA13712; Mon, 1 Apr 2002 18:06:16 -0600 (CST) Message-ID: <3CA8F54D.7167711E@ericsson.com> Date: Mon, 01 Apr 2002 16:03:25 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host AVP as is. After all it is only optional and it seems like some may find it useful. Comments / objections to this. /Tony Sivasundar Ramamurthy wrote: > Hello, > > I might have a couple of uses for this avp. > > 1. The assumption here is that the FA-HA key is not session specific > (see Issue: 317). > > When the HAR containing the HA-FA key is received by the HA, the HA > needs to know which FA the FA-HA key is for. The COA in the > reg-request must be one of the FA's addresses but need not be the > address from which the FA forwards UDP reg requests to the HA. The > FQDN in FA-Host AVP might be a more reliable way to identify the FA > and store the key against. > > When a UDP MIP request containing a FA-HA auth ext is received, the HA > can get the host name of the FA from the source address (DNS) and > determine if it has a SA to that FA. Hopefully the address the FA uses > to forward the request matches against the hostname retrived from the > FA-Host AVP in the HAR. > > NOTE: If this usage, and thus the necessity of this AVP, makes sense, > maybe we can extend it as an argument for requiring support for the > GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg > requests will let the HA find a key for the FA (without using DNS) and > authenticate it. > > 2. Section 1.3 in the MIP draft has text that says: > > "...it is necessary for the resulting HAR received by the HA to be > identified as a continuation of an existing session". > > Maybe the FQDN in the FA-Host-AVP is a reliable way to determine > session continuation?? > > thanks! > > Siva From owner-aaa-wg@merit.edu Mon Apr 1 19:26:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20137 for ; Mon, 1 Apr 2002 19:26:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 993CC9124C; Mon, 1 Apr 2002 19:26:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B13C9124D; Mon, 1 Apr 2002 19:26:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E3969124C for ; Mon, 1 Apr 2002 19:26:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FC9A5DDDD; Mon, 1 Apr 2002 19:26:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id AD7535DDDA for ; Mon, 1 Apr 2002 19:26:28 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g320BSl03771; Mon, 1 Apr 2002 18:11:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g320BRV04687; Mon, 1 Apr 2002 18:11:27 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA08297; Mon, 1 Apr 2002 18:11:26 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA13790; Mon, 1 Apr 2002 18:11:25 -0600 (CST) Message-ID: <3CA8F682.1C595057@ericsson.com> Date: Mon, 01 Apr 2002 16:08:34 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Lau Cc: aaa-wg@merit.edu, sivasundar_ramamurthy@hp.com, sramam@cup.hp.com Subject: Re: [AAA-WG]: Issue 317:FA-HA Key References: <200204012250.OAA08296@strtio1.cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Why would it be interpretability problems ? /Tony Joe Lau wrote: > > > This message uses a character set that is not supported by the > Internet Service. To view the original message content, open the > attached message. If the text doesn't display correctly, save the > attachment to disk, and then open it using a viewer that can display > the original character set. <> From owner-aaa-wg@merit.edu Mon Apr 1 19:34:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20335 for ; Mon, 1 Apr 2002 19:34:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 424F29124D; Mon, 1 Apr 2002 19:34:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 101529124F; Mon, 1 Apr 2002 19:34:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D387D9124D for ; Mon, 1 Apr 2002 19:33:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4A6B5DDDD; Mon, 1 Apr 2002 19:33:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 95B0D5DDDA for ; Mon, 1 Apr 2002 19:33:59 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 2DEEC4005CB; Mon, 1 Apr 2002 16:33:57 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA04854; Mon, 1 Apr 2002 16:34:27 -0800 (PST) Date: Mon, 1 Apr 2002 16:34:26 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: Joe Lau , AAA Working Group Subject: Re: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: <3CA8F682.1C595057@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Tony, On Mon, 1 Apr 2002, Tony Johansson wrote: > Why would it be interpretability problems ? If the HA and FA folllow different implementations, there might be unnecessary authentication failures. Consider the case when the FA keeps one FA-HA key per session, and the HA keeps one key per FA and uses it for all sessions. If there are multiple MNs of that HA visiting the FA, re-registrations of some MN's may result in in FA-HA authentication failures -- FA is using the key from a specific session, while the HA's "global" key to that FA is obtained from a HAR from another session. Siva From owner-aaa-wg@merit.edu Mon Apr 1 19:43:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20491 for ; Mon, 1 Apr 2002 19:43:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2E229124F; Mon, 1 Apr 2002 19:43:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86D5E91250; Mon, 1 Apr 2002 19:43:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 684FC9124F for ; Mon, 1 Apr 2002 19:43:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4565D5DDDA; Mon, 1 Apr 2002 19:43:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 159655DDFC for ; Mon, 1 Apr 2002 19:43:15 -0500 (EST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel11.hp.com (Postfix) with ESMTP id 7B2516003A1; Mon, 1 Apr 2002 16:43:12 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA08558; Mon, 1 Apr 2002 16:44:08 -0800 (PST) Date: Mon, 1 Apr 2002 16:44:08 -0800 (PST) From: Joe Lau Message-Id: <200204020044.QAA08558@strtio1.cup.hp.com> To: tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: <3CA8F682.1C595057@ericsson.com> Cc: aaa-wg@merit.edu, jlau@strtio1.cup.hp.com, sivasundar_ramamurthy@hp.com, sramam@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, > Why would it be interpretability problems ? Let's say FA (from vendor A) implemented session-specific FA-HA key and the HA (from vendor B) implemented "global" FA-HA key. Two MNs from the HA visisted the FA's foreign network. The FA requested a separate FA-HA key from the AAAH for each MN's session. Yet, the HA simply uses the latest FA-HA key generated by the AAAH. Under this circumstance, one of the MN's registration request will fail the FA-HA authentication due mismatch of FA-HA key. Won't it? Regards, Joe From owner-aaa-wg@merit.edu Mon Apr 1 20:20:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20837 for ; Mon, 1 Apr 2002 20:20:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C9F391250; Mon, 1 Apr 2002 20:20:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C669B91253; Mon, 1 Apr 2002 20:20:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60FA191250 for ; Mon, 1 Apr 2002 20:20:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0A325DDEF; Mon, 1 Apr 2002 20:20:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 3A5C85DD8C for ; Mon, 1 Apr 2002 20:20:17 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g321KGl22879; Mon, 1 Apr 2002 19:20:16 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g321KG114314; Mon, 1 Apr 2002 19:20:16 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA13780; Mon, 1 Apr 2002 19:20:15 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA14732; Mon, 1 Apr 2002 19:20:14 -0600 (CST) Message-ID: <3CA906A2.89E6C760@ericsson.com> Date: Mon, 01 Apr 2002 17:17:22 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Joe Lau , AAA Working Group Subject: Re: [AAA-WG]: Issue 317:FA-HA Key References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit But each FA-HA key also has SPI, which helps out to identify the key. Thus, when a HA receives a MIP RRQ from the FA, the HA must identify the the right FA-HA key to be used by looking at the received FA-HA SPI in the FA-HA auth. /Tony Sivasundar Ramamurthy wrote: > Hello Tony, > > On Mon, 1 Apr 2002, Tony Johansson wrote: > > > Why would it be interpretability problems ? > > If the HA and FA folllow different implementations, there might be > unnecessary authentication failures. Consider the case when the FA > keeps one FA-HA key per session, and the HA keeps one key per FA and > uses it for all sessions. If there are multiple MNs of that HA > visiting the FA, re-registrations of some MN's may result in in FA-HA > authentication failures -- FA is using the key from a specific > session, while the HA's "global" key to that FA is obtained from a HAR > from another session. > > Siva From owner-aaa-wg@merit.edu Mon Apr 1 20:53:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21504 for ; Mon, 1 Apr 2002 20:53:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8846491251; Mon, 1 Apr 2002 20:53:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53F5E91252; Mon, 1 Apr 2002 20:53:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 131AE91251 for ; Mon, 1 Apr 2002 20:53:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBED35DDD9; Mon, 1 Apr 2002 20:53:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 854D95DDB5 for ; Mon, 1 Apr 2002 20:53:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g321r6l03069; Mon, 1 Apr 2002 19:53:06 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g321r6904212; Mon, 1 Apr 2002 19:53:06 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA16286; Mon, 1 Apr 2002 19:53:06 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA15183; Mon, 1 Apr 2002 19:53:05 -0600 (CST) Message-ID: <3CA90E55.559465D1@ericsson.com> Date: Mon, 01 Apr 2002 17:50:13 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Issue #299 and #301 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit I vote for #2 below, which can be fixed by adding something like the following in the draft-johansson-mip-aaa-nai-00.txt: " 4. HA Identity subtype ... A mobile node, which request a specific HA IP address at the initial authentication MUST also provide the HA Identity subtype ... " /Tony Bob Kopacz wrote: > Hi Tony, > > At this time, I have nothing more to offer in terms of an issue#299 > solution, but I have another related snag, the solution to which can be > part of the issue#299 solution. > > This problem isn't with the MN-handoff, but is with the initial AMR for > a mobile session, and has to do with the problem of mapping the HA's IP > address to the HA's identity. > > Here we go: > > Suppose a MN initially hooks up with an FA in some foreign network, and > the MN knows his HA's IP address in the home network. So the AMR > carries a MIP-Home-Agent-Address AVP, and is routed to some AAAH in the > home network. > > When the AAAH receives this AMR, the AAAH will want to send an HAR to > the HA, and will need the HA's identity for the HAR's Destination-Host > AVP. > > If the targeted HA is a direct peer of the AAAH, then this is no problem. > The AAAH just looks into his peer table for a peer with an IP address > matching the value of the AMR's MIP-Home-Agent-Address AVP. > > But if the HA is not a direct peer of the AAAH, then the AAAH has to > somehow map the HA's IP address to the HA's identity. > > Three ideas pop into mind: > > 1. Require that all home-network HAs be direct peers of all the > home-network AAAHs. > > or > > 2. Require an MN who remembers his HA's IP address between sessions to > also remember the HA's identity between sessions, and send both of these > HA identification items in the Registration Request. The FA would > extract both of these items from the Registration Request, and send > them as Diameter AVPs in the initial AMR. > > or > > 3. Indicate that the AAAHs must have some mechanism, not specified in > the protocol, of mapping the home-network's HA IP addresses into > DiameterIdentities. > > Bob K. > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Tony Johansson > > Sent: Monday, March 25, 2002 2:30 AM > > To: aaa-wg > > Cc: Bob Kopacz; Fredrik Johansson; Johan Johansson; David Spence; Pat R. > > Calhoun > > Subject: [AAA-WG]: Issue #299 and #301 > > > > > > All, > > > > During, the AAA working group meeting at IETF53 I presented the > > issues #299 and > > #301 and two alternative ways in which we could workout a solution to the open > > issues - see below: > > > > Alt1: Clarifications / new requirements without any new dependencies to MIP. > > ------------------------------------------------------------------------------ > > > > AAAH > > - Require that each subdomain of a realm is authorized/authenticated > > by exactly > > one AAAH. So while a home network may have multiple AAAH's, each > > subdomain will > > have exactly one AAAH. > > > > - Or, require that, if the home realm has multiple AAA servers to > > which the same > > user can be routed to, then there MUST be a synchronization > > mechanism between the AAAH servers. However, the specific synchronization > > mechanism is beyond the scope of this spec. > > > > AAAF > > - How to map HA IP address to HA FQDN is still open. Reverse DNS look > > up is not > > at all a straightforward solution for this… > > > > > > Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. > > ----------------------------------------------------------------------------- > > > > AAAH > > - Require that the MN support the GNAIE draft, updated to include the > > definition > > of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI > > would be included to guarantee that a registered user always ends up > > in the same > > initial AAAH. > > > > AAAF > > - The mapping of the HA IP address and HA FQDN, Host and realm would be > > automatically solved, since this would be included in the MIP RegReq as well. > > > > There was a very clear and strong consensus that alternative 2 would be by far > > the best solution. However, this means more work and dependencies > > to the MIP working group and the goal is set to have the Diameter MIPv4 appl. > > draft in working group last call by the April 2nd. Looking at the > > GNAIE draft, I done see that much work needs to be done to make it fulfill our > > needs, so to me it could easily be done in time, but the big > > question is how quickly could it be pushed through the MIP working > > group and go > > to last call? I have sent the question MIP wg and I hope to soon get answer > > back. > > > > Regards, > > > > Tony > > > > > > > > From owner-aaa-wg@merit.edu Mon Apr 1 21:05:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21713 for ; Mon, 1 Apr 2002 21:05:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3840791252; Mon, 1 Apr 2002 21:05:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 081DB91253; Mon, 1 Apr 2002 21:05:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74CCB91252 for ; Mon, 1 Apr 2002 21:05:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EC4F5DDD9; Mon, 1 Apr 2002 21:05:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id BB5685DD8C for ; Mon, 1 Apr 2002 21:05:09 -0500 (EST) Received: (qmail 7694 invoked by uid 500); 2 Apr 2002 02:05:09 -0000 Date: Mon, 1 Apr 2002 20:05:08 -0600 From: David Frascone To: Bob Kopacz Cc: Tony Johansson , aaa-wg@merit.edu, DSpence@InterlinkNetworks.com Subject: Re: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 Message-ID: <20020402020508.GQ7827@newman.frascone.com> Mail-Followup-To: Bob Kopacz , Tony Johansson , aaa-wg@merit.edu, DSpence@Interlinknetworks.com References: <3CA8CF9C.FCE37531@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk My only fear is that there are *many* useful AVPs that we can spend WAY too much time defining. While I do agree that Event-Timestamp seems like a very good idea, I'm afraid that if I vote *yes* to this change, there will be a flood of new useful AVPs that people want inserted into the base drafts. Since you *can* put in the Event-Timestamp now, I don't see any reason to specify it in the draft. So, I vote *no* (Even though, I think the AVP is a good idea) -Dave On Monday, 01 Apr 2002, Bob Kopacz wrote: > > Hi Tony, > > > > OK, I'll bite. It seems to me that allowing the Event-Timestamp AVP > couldn't > do any harm, and might be helpful. The virtue of the Event-Timestamp > AVP is > that mobility agents can send multiple accounting messages (start, > interim, > stop), all of which will reflect the same session start-time. That > is, a MA > can send an Accounting Start with an Event-Timestamp(value=T). N > seconds > later, the MA can send an Accounting Stop with an > Event-Timestamp(value=T+N) > and Acct-Session-Time(value=N). > > > > If you include your proposed text, you might consider changing the > type > from Unsigned32 to Time (an Unsigned32-derived type defined in the > Base). > > > > Bob K. > > > From: [1]owner-aaa-wg@merit.edu on behalf of Tony Johansson > [[2]tony.johansson@ericsson.com] > > Sent: Monday, April 01, 2002 4:23 PM > > To: [3]aaa-wg@merit.edu; [4]DSpence@Interlinknetworks.com > > Subject: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 > > Hello David and All, > > I haven't seen any comments on this issue, so I'm not sure what > people think about this. > > > > If we think it's useful, I could add something like the following: > > > > "7.5 Event-Timestamp AVP > > > > The The Event-Timestamp (AVP Code 55) is of type Unsigned32, and MAY > be > > included in an Accounting-Request message to record the time that > this event > > occurred on the mobility agent, in seconds since January 1, 1970 > 00:00 UTC." > > > > Comments please, > > > > Tony > > > > > > Issue 296: Possible new AVP for MobileIPv4 > > Submitter name: David Spence > > Submitter email address: [5]DSpence@Interlinknetworks.com > > Date first submitted: March 4, 2002 > > Reference: > > Document: MobileIPv4 > > Comment type: T > > Priority: 2 > > Section: > > Rationale/Explanation of issue: > > > > The following attribute is defined in RADIUS for use in accounting > > messages.It might be useful in the MobileIPv4 application. > > > > CODE NAME RFC > > --------- ------------------ ---- > > 55 Event-Timestamp 2869 > > > > Requested change: > > > > Consider adding this attribute to MobileIPv4 as a Diameter AVP. > > > > Note: This AVP will need to be defined in NASREQ for RADIUS > > compatibility. See issue TBA. > > > > References > > 1. mailto:owner-aaa-wg@merit.edu > 2. mailto:tony.johansson@ericsson.com > 3. mailto:aaa-wg@merit.edu > 4. mailto:DSpence@Interlinknetworks.com > 5. mailto:DSpence@Interlinknetworks.com -- David Frascone He who laughs last probably made a backup. From owner-aaa-wg@merit.edu Tue Apr 2 02:53:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09137 for ; Tue, 2 Apr 2002 02:53:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC0F591253; Tue, 2 Apr 2002 02:53:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73BF391254; Tue, 2 Apr 2002 02:53:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4927F91253 for ; Tue, 2 Apr 2002 02:53:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EE905DDE2; Tue, 2 Apr 2002 02:53:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5F9CA5DD9C for ; Tue, 2 Apr 2002 02:53:16 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g327rR510597 for ; Tue, 2 Apr 2002 10:53:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 10:53:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 10:53:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 318 revisted: Host-IP-Address AVP in CER and CEA is redundant Date: Tue, 2 Apr 2002 10:52:59 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWcTyP3Clcq3ZuQnS36H+Z/IUP/ADQ6TxAABYEzcA= From: To: , Cc: X-OriginalArrivalTime: 02 Apr 2002 07:53:11.0721 (UTC) FILETIME=[6FC49190:01C1DA1B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA09137 Hi all, Looking through this issue one more time, I think that a point may be that: 1* { Host-IP-Address } may not be correct. Would DiameterURI be better? The reasons listed in the issue below are part of the reasoning. The question I have is, is Host-IP-Address OK, or do we need something more like DiameterURI? John Issue 318:Host-IP-Address AVP in CER and CEA is redundant Submitter name: Ghadiyaram Venkata Kishore Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, Date first submitted: March 28, 2002 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. Requested change: Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). ::= < Diameter Header: 257 > { Result-Code } { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] [ Error-Message ] * [ Failed-AVP ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] ::= < Diameter Header: 257, REQ > { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] From owner-aaa-wg@merit.edu Tue Apr 2 03:13:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09528 for ; Tue, 2 Apr 2002 03:13:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E026C91254; Tue, 2 Apr 2002 03:12:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9E5591255; Tue, 2 Apr 2002 03:12:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52A4E91254 for ; Tue, 2 Apr 2002 03:12:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B9AF5DDFE; Tue, 2 Apr 2002 03:12:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5351A5DD9C for ; Tue, 2 Apr 2002 03:12:47 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g328D2527472 for ; Tue, 2 Apr 2002 11:13:02 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:12:46 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:12:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: Issue 318 revisted: Host-IP-Address AVP in CER and CEA is redundant Date: Tue, 2 Apr 2002 11:12:44 +0300 Message-ID: <9E3407CE45911B4097632389B77B202306D081@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Host-IP-Address AVP in CER and CEA is redundant Thread-Index: AcHWcTyP3Clcq3ZuQnS36H+Z/IUP/ADQ6TxAABYEzcAAA/pgUA== From: To: , Cc: X-OriginalArrivalTime: 02 Apr 2002 08:12:46.0106 (UTC) FILETIME=[2BC17FA0:01C1DA1E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09528 Hi, I think that Host-ip-address is not sufficient. It should be a list of DiameterURI. For example we can consider a hypothetical AVP, Host-URI of type DiameterURI then CER should contain *[Host-URI] I suggest the AVP to be optional because, there can be cases where the node does not want to suggest any other URI. Moreover URIs are anyhow known during peer discovery, so sending them as part of CER/CEA is not always necessary. Kishore -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 02. April 2002 10:53 To: dave@frascone.com; Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: Issue 318 revisted: Host-IP-Address AVP in CER and CEA is redundant Hi all, Looking through this issue one more time, I think that a point may be that: 1* { Host-IP-Address } may not be correct. Would DiameterURI be better? The reasons listed in the issue below are part of the reasoning. The question I have is, is Host-IP-Address OK, or do we need something more like DiameterURI? John Issue 318:Host-IP-Address AVP in CER and CEA is redundant Submitter name: Ghadiyaram Venkata Kishore Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, Date first submitted: March 28, 2002 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message can be obtained from the transport layer as this information is maintained by the transport layer as part of TCP connection or SCTP association. So sending this information as part of Diameter payload is redundant. If alternate peers have to be provided through CER/CEA then we need a list of DiameterURIs, just the IPAddress of the peers is of no use. Requested change: Remove Host-IP-Address AVP from the specification of CER and CEA (both in the text and te ABNF). ::= < Diameter Header: 257 > { Result-Code } { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] [ Error-Message ] * [ Failed-AVP ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] ::= < Diameter Header: 257, REQ > { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] From owner-aaa-wg@merit.edu Tue Apr 2 08:46:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14809 for ; Tue, 2 Apr 2002 08:46:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 470939125C; Tue, 2 Apr 2002 08:45:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 081C79125B; Tue, 2 Apr 2002 08:45:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E3669125A for ; Tue, 2 Apr 2002 08:45:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 581A05DDE1; Tue, 2 Apr 2002 08:45:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 85E0C5DD9E for ; Tue, 2 Apr 2002 08:45:23 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g32Di6o32138; Tue, 2 Apr 2002 15:44:10 +0200 Message-ID: <3CA9B574.8040601@ipunplugged.com> Date: Tue, 02 Apr 2002 15:43:16 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: David Frascone Cc: Bob Kopacz , Tony Johansson , aaa-wg@merit.edu, john.loughney@nokia.com Subject: Re: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 References: <3CA8CF9C.FCE37531@ericsson.com> <20020402020508.GQ7827@newman.frascone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think *a* timestamp for accounting records is useful when performing fault recovery as described in 9.4 of the base draft. I think it might even be required to trace users' usage correctly. I could have sworn that an avp was introduced for this purpose in the base draft sometime just before the IETF meeting but I can find no evidence of this searching the mail archive at merit. Then again I probably couldn't find this message using the search function there. I want a timestamp communicated in all ACRs for this reason but in my opinion it is inherent in all accounting and as such belongs in the base draft and not the mobile ip draft. j David Frascone wrote: >My only fear is that there are *many* useful AVPs that we can spend WAY too >much time defining. > >While I do agree that Event-Timestamp seems like a very good idea, I'm >afraid that if I vote *yes* to this change, there will be a flood of new >useful AVPs that people want inserted into the base drafts. > >Since you *can* put in the Event-Timestamp now, I don't see any reason to >specify it in the draft. > >So, I vote *no* (Even though, I think the AVP is a good idea) > >-Dave > > >On Monday, 01 Apr 2002, Bob Kopacz wrote: > >> Hi Tony, >> >> >> >> OK, I'll bite. It seems to me that allowing the Event-Timestamp AVP >> couldn't >> do any harm, and might be helpful. The virtue of the Event-Timestamp >> AVP is >> that mobility agents can send multiple accounting messages (start, >> interim, >> stop), all of which will reflect the same session start-time. That >> is, a MA >> can send an Accounting Start with an Event-Timestamp(value=T). N >> seconds >> later, the MA can send an Accounting Stop with an >> Event-Timestamp(value=T+N) >> and Acct-Session-Time(value=N). >> >> >> >> If you include your proposed text, you might consider changing the >> type >> from Unsigned32 to Time (an Unsigned32-derived type defined in the >> Base). >> >> >> >> Bob K. >> >> > From: [1]owner-aaa-wg@merit.edu on behalf of Tony Johansson >> [[2]tony.johansson@ericsson.com] >> > Sent: Monday, April 01, 2002 4:23 PM >> > To: [3]aaa-wg@merit.edu; [4]DSpence@Interlinknetworks.com >> > Subject: [AAA-WG]: Issue 296: Possible new AVP for MobileIPv4 >> > Hello David and All, >> > I haven't seen any comments on this issue, so I'm not sure what >> people think about this. >> > >> > If we think it's useful, I could add something like the following: >> > >> > "7.5 Event-Timestamp AVP >> > >> > The The Event-Timestamp (AVP Code 55) is of type Unsigned32, and MAY >> be >> > included in an Accounting-Request message to record the time that >> this event >> > occurred on the mobility agent, in seconds since January 1, 1970 >> 00:00 UTC." >> > >> > Comments please, >> > >> > Tony >> > >> > >> > Issue 296: Possible new AVP for MobileIPv4 >> > Submitter name: David Spence >> > Submitter email address: [5]DSpence@Interlinknetworks.com >> > Date first submitted: March 4, 2002 >> > Reference: >> > Document: MobileIPv4 >> > Comment type: T >> > Priority: 2 >> > Section: >> > Rationale/Explanation of issue: >> > >> > The following attribute is defined in RADIUS for use in accounting >> > messages.It might be useful in the MobileIPv4 application. >> > >> > CODE NAME RFC >> > --------- ------------------ ---- >> > 55 Event-Timestamp 2869 >> > >> > Requested change: >> > >> > Consider adding this attribute to MobileIPv4 as a Diameter AVP. >> > >> > Note: This AVP will need to be defined in NASREQ for RADIUS >> > compatibility. See issue TBA. >> > >> >>References >> >> 1. mailto:owner-aaa-wg@merit.edu >> 2. mailto:tony.johansson@ericsson.com >> 3. mailto:aaa-wg@merit.edu >> 4. mailto:DSpence@Interlinknetworks.com >> 5. mailto:DSpence@Interlinknetworks.com >> > From owner-aaa-wg@merit.edu Tue Apr 2 10:04:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18184 for ; Tue, 2 Apr 2002 10:04:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7E5A9125A; Tue, 2 Apr 2002 10:04:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83C2A9125B; Tue, 2 Apr 2002 10:04:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EB2E9125A for ; Tue, 2 Apr 2002 10:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16D1A5DE1A; Tue, 2 Apr 2002 10:04:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id F21475DE0F for ; Tue, 2 Apr 2002 10:04:07 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g32Eruo03510; Tue, 2 Apr 2002 16:53:56 +0200 Message-ID: <3CA9C5D1.8000201@ipunplugged.com> Date: Tue, 02 Apr 2002 16:53:05 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Sivasundar Ramamurthy , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: <3CA8F54D.7167711E@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit But I created this issue specifically because it is mandatory in HARs and for some reason I can not even speculate about in HAAs. As for Sivasundar's use for it I have been trying to find time to think it through properly but not found it. I'll try to make some comments on it though and then Sivasundar can correct my mistakes. The only text in the draft that touches this avp says that it is a copy of the Origin-Host avp of the AMR. This means that you are keying your SA on the diameter interface instead of the mobile ip tunneling interface. I am not sure if it's a good idea to use something that is invented by diameter to key the SA rather than something that the mobile ip layer of the FA sends. A couple of weeks ago I went through the latest mobile ip draft together with Fredrik to see if this split between the tunneling interface and the control interface is supported in "raw" mobile ip. It doesn't seem to be explicitly disallowed at any rate, but I am still not convinced that it can in fact be made to work. In summary, if the FA-Host avp is used you can use the diameter interface to key your SA and otherwise you need to use the tunneling interface. Your thoughts on this Sivasundar? Regarding detecting session continuation on the clients: I suppose the issue arises only for stateless clients? And for stateless clients you are moving the detection to the mobile ip layer, right? j Tony Johansson wrote: >All, > >My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host >AVP as is. After all it is only optional and it seems like some may find >it useful. > >Comments / objections to this. > >/Tony > >Sivasundar Ramamurthy wrote: > >>Hello, >> >>I might have a couple of uses for this avp. >> >>1. The assumption here is that the FA-HA key is not session specific >>(see Issue: 317). >> >>When the HAR containing the HA-FA key is received by the HA, the HA >>needs to know which FA the FA-HA key is for. The COA in the >>reg-request must be one of the FA's addresses but need not be the >>address from which the FA forwards UDP reg requests to the HA. The >>FQDN in FA-Host AVP might be a more reliable way to identify the FA >>and store the key against. >> >>When a UDP MIP request containing a FA-HA auth ext is received, the HA >>can get the host name of the FA from the source address (DNS) and >>determine if it has a SA to that FA. Hopefully the address the FA uses >>to forward the request matches against the hostname retrived from the >>FA-Host AVP in the HAR. >> >>NOTE: If this usage, and thus the necessity of this AVP, makes sense, >>maybe we can extend it as an argument for requiring support for the >>GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg >>requests will let the HA find a key for the FA (without using DNS) and >>authenticate it. >> >>2. Section 1.3 in the MIP draft has text that says: >> >>"...it is necessary for the resulting HAR received by the HA to be >>identified as a continuation of an existing session". >> >>Maybe the FQDN in the FA-Host-AVP is a reliable way to determine >>session continuation?? >> >>thanks! >> >>Siva >> > From owner-aaa-wg@merit.edu Tue Apr 2 10:11:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18443 for ; Tue, 2 Apr 2002 10:11:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 610139125B; Tue, 2 Apr 2002 10:10:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 229A39125D; Tue, 2 Apr 2002 10:10:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1678A9125B for ; Tue, 2 Apr 2002 10:10:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id E072C5DE0E; Tue, 2 Apr 2002 10:10:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 2D9CB5DDC6 for ; Tue, 2 Apr 2002 10:10:54 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g32EAqi02016; Tue, 2 Apr 2002 16:10:53 +0200 Message-ID: <3CA9C9C4.4050508@ipunplugged.com> Date: Tue, 02 Apr 2002 17:09:56 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Issue #299 and #301 References: <3CA90E55.559465D1@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I thought #2 was required already? #1 is interesting since it touches on what network configurations are even possible. I'll go over some different network scenarios and put together an issue. The only thing I am quite certain of right now is that the suggested configuration for hierarchical networks does *not* work, at least not as expected. The intuitive configuration makes the AMRs end up at the HAs for instance. More on this later. j Tony Johansson wrote: >I vote for #2 below, which can be fixed by adding something like the following in >the draft-johansson-mip-aaa-nai-00.txt: > >" 4. HA Identity subtype > > ... > > A mobile node, which request a specific HA IP address at the > initial authentication MUST also provide the HA Identity subtype > > ... " > > > >/Tony > >Bob Kopacz wrote: > >>Hi Tony, >> >>At this time, I have nothing more to offer in terms of an issue#299 >>solution, but I have another related snag, the solution to which can be >>part of the issue#299 solution. >> >>This problem isn't with the MN-handoff, but is with the initial AMR for >>a mobile session, and has to do with the problem of mapping the HA's IP >>address to the HA's identity. >> >>Here we go: >> >>Suppose a MN initially hooks up with an FA in some foreign network, and >>the MN knows his HA's IP address in the home network. So the AMR >>carries a MIP-Home-Agent-Address AVP, and is routed to some AAAH in the >>home network. >> >>When the AAAH receives this AMR, the AAAH will want to send an HAR to >>the HA, and will need the HA's identity for the HAR's Destination-Host >>AVP. >> >>If the targeted HA is a direct peer of the AAAH, then this is no problem. >>The AAAH just looks into his peer table for a peer with an IP address >>matching the value of the AMR's MIP-Home-Agent-Address AVP. >> >>But if the HA is not a direct peer of the AAAH, then the AAAH has to >>somehow map the HA's IP address to the HA's identity. >> >>Three ideas pop into mind: >> >>1. Require that all home-network HAs be direct peers of all the >>home-network AAAHs. >> >>or >> >>2. Require an MN who remembers his HA's IP address between sessions to >>also remember the HA's identity between sessions, and send both of these >>HA identification items in the Registration Request. The FA would >>extract both of these items from the Registration Request, and send >>them as Diameter AVPs in the initial AMR. >> >>or >> >>3. Indicate that the AAAHs must have some mechanism, not specified in >>the protocol, of mapping the home-network's HA IP addresses into >>DiameterIdentities. >> >>Bob K. >> >>>-----Original Message----- >>>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >>>Tony Johansson >>>Sent: Monday, March 25, 2002 2:30 AM >>>To: aaa-wg >>>Cc: Bob Kopacz; Fredrik Johansson; Johan Johansson; David Spence; Pat R. >>>Calhoun >>>Subject: [AAA-WG]: Issue #299 and #301 >>> >>> >>>All, >>> >>>During, the AAA working group meeting at IETF53 I presented the >>>issues #299 and >>>#301 and two alternative ways in which we could workout a solution to the open >>>issues - see below: >>> >>>Alt1: Clarifications / new requirements without any new dependencies to MIP. >>>------------------------------------------------------------------------------ >>> >>>AAAH >>>- Require that each subdomain of a realm is authorized/authenticated >>>by exactly >>>one AAAH. So while a home network may have multiple AAAH's, each >>>subdomain will >>>have exactly one AAAH. >>> >>>- Or, require that, if the home realm has multiple AAA servers to >>>which the same >>>user can be routed to, then there MUST be a synchronization >>>mechanism between the AAAH servers. However, the specific synchronization >>>mechanism is beyond the scope of this spec. >>> >>> AAAF >>>- How to map HA IP address to HA FQDN is still open. Reverse DNS look >>>up is not >>>at all a straightforward solution for this... >>> >>> >>>Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. >>>----------------------------------------------------------------------------- >>> >>>AAAH >>>- Require that the MN support the GNAIE draft, updated to include the >>>definition >>>of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI >>>would be included to guarantee that a registered user always ends up >>>in the same >>>initial AAAH. >>> >>>AAAF >>>- The mapping of the HA IP address and HA FQDN, Host and realm would be >>>automatically solved, since this would be included in the MIP RegReq as well. >>> >>>There was a very clear and strong consensus that alternative 2 would be by far >>>the best solution. However, this means more work and dependencies >>>to the MIP working group and the goal is set to have the Diameter MIPv4 appl. >>>draft in working group last call by the April 2nd. Looking at the >>>GNAIE draft, I done see that much work needs to be done to make it fulfill our >>>needs, so to me it could easily be done in time, but the big >>>question is how quickly could it be pushed through the MIP working >>>group and go >>>to last call? I have sent the question MIP wg and I hope to soon get answer >>>back. >>> >>>Regards, >>> >>>Tony >>> >>> >>> >>> > From owner-aaa-wg@merit.edu Tue Apr 2 11:56:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22831 for ; Tue, 2 Apr 2002 11:56:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59F5991265; Tue, 2 Apr 2002 11:56:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25AD191266; Tue, 2 Apr 2002 11:56:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0334791265 for ; Tue, 2 Apr 2002 11:56:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7D315DDBD; Tue, 2 Apr 2002 11:56:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id A74F15DDA4 for ; Tue, 2 Apr 2002 11:56:13 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 26079E0075B; Tue, 2 Apr 2002 08:56:08 -0800 (PST) Received: from hpindsra (sramam@hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id IAA06019; Tue, 2 Apr 2002 08:56:39 -0800 (PST) Date: Tue, 2 Apr 2002 08:56:39 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: Joe Lau , AAA Working Group Subject: Re: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: <3CA906A2.89E6C760@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Tony, On Mon, 1 Apr 2002, Tony Johansson wrote: > But each FA-HA key also has SPI, which helps out to identify the key. > Thus, when a HA receives a MIP RRQ from the FA, the HA must identify the > the right FA-HA key to be used by looking at the received FA-HA SPI in the > FA-HA auth. What I think you are saying is that the HA maintains multiple HA-FA keys (one for each session?), but can expect the FA to use any of those keys. The HA authenticates the FA by selecting the key that matches the SPI used by the FA, even if the key is from a different session. And in order to make this work, the HA needs to make sure that each session key has a unique SPI. This is different from the two implementations I was referring in my original email: 1. The HA implementation maintains only one key to the FA. Everytime it get a new key to the FA, it will refresh the existing key (if any) and assign the same SPI to the new key. This is the only key that will be used for all communication between the FA and HA. (corresponds to "any key") 2. The FA implementation maintains HA-FA key for each session, which is the one and only key that can be used for any communication between the FA and HA for that session -- the FA will expect the authenticator from the HA to have been created only using that session's key (and SPI). (corresponds to "session key"). I dont think there is anything in the draft that says that the above two interpretations are wrong. Even if it may seem that "multiple HA-FA keys indexed by SPI" is the correct way to do it, I feel that it is better if we can make certain issues non-implementation specific to eliminate chances of unnecessary HA-FA authentication failures. thanks, Siva > /Tony > > Sivasundar Ramamurthy wrote: > > > Hello Tony, > > > > On Mon, 1 Apr 2002, Tony Johansson wrote: > > > > > Why would it be interpretability problems ? > > > > If the HA and FA folllow different implementations, there might be > > unnecessary authentication failures. Consider the case when the FA > > keeps one FA-HA key per session, and the HA keeps one key per FA and > > uses it for all sessions. If there are multiple MNs of that HA > > visiting the FA, re-registrations of some MN's may result in in FA-HA > > authentication failures -- FA is using the key from a specific > > session, while the HA's "global" key to that FA is obtained from a HAR > > from another session. > > > > Siva > > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== From owner-aaa-wg@merit.edu Tue Apr 2 14:36:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29395 for ; Tue, 2 Apr 2002 14:36:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76FBF9126F; Tue, 2 Apr 2002 14:34:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1386D91270; Tue, 2 Apr 2002 14:34:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 921CC9126F for ; Tue, 2 Apr 2002 14:34:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BE525DE5F; Tue, 2 Apr 2002 14:34:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 3CDF75DDCA for ; Tue, 2 Apr 2002 14:34:54 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id BF2AE400606; Tue, 2 Apr 2002 11:34:49 -0800 (PST) Received: from hpindsra (sramam@hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id LAA06199; Tue, 2 Apr 2002 11:35:16 -0800 (PST) Date: Tue, 2 Apr 2002 11:35:16 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Johan Johansson Cc: Tony Johansson , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host In-Reply-To: <3CA9C5D1.8000201@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, 2 Apr 2002, Johan Johansson wrote: > But I created this issue specifically because it is mandatory in HARs > and for some reason I can not even speculate about in HAAs. As for > Sivasundar's use for it I have been trying to find time to think it > through properly but not found it. I'll try to make some comments on it > though and then Sivasundar can correct my mistakes. > > The only text in the draft that touches this avp says that it is a copy > of the Origin-Host avp of the AMR. This means that you are keying your > SA on the diameter interface instead of the mobile ip tunneling > interface. I am not sure if it's a good idea to use something that is > invented by diameter to key the SA rather than something that the mobile > ip layer of the FA sends. but does not the Origin-Host contain the FQDN of the FA? My assumption is that a DNS lookup on this FQDN might give us all the control addresses used by the FA. > A couple of weeks ago I went through the latest mobile ip draft together > with Fredrik to see if this split between the tunneling interface and > the control interface is supported in "raw" mobile ip. It doesn't seem > to be explicitly disallowed at any rate, but I am still not convinced > that it can in fact be made to work. Cant this happen when the "r" bit is set on the agent adv and the MN is using a co-located COA? Or if the advertised COA and the the control interface are different? > In summary, if the FA-Host avp is > used you can use the diameter interface to key your SA and otherwise you > need to use the tunneling interface. Your thoughts on this Sivasundar? This issue is actually related to issue #317 regarding the FA-HA key. Based on the resolution on that, we might be able to get rid of the need for this AVP wrt the FA-HA key. > Regarding detecting session continuation on the clients: I suppose the > issue arises only for stateless clients? And for stateless clients you > are moving the detection to the mobile ip layer, right? but I was referring to the support for Handoff issues in Diameter MIP draft section 1.3. Using the FA-Host-AVP, the HA can determine if the MN has moved to a new realm or a different FA in the same realm. My understanding is that the HA maintains MN session per Realm, not per FA. But do remember that this particular usage of the AVP is a guess of mine.. :-) thanks, Siva > j > > Tony Johansson wrote: > > >All, > > > >My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host > >AVP as is. After all it is only optional and it seems like some may find > >it useful. > > > >Comments / objections to this. > > > >/Tony > > > >Sivasundar Ramamurthy wrote: > > > >>Hello, > >> > >>I might have a couple of uses for this avp. > >> > >>1. The assumption here is that the FA-HA key is not session specific > >>(see Issue: 317). > >> > >>When the HAR containing the HA-FA key is received by the HA, the HA > >>needs to know which FA the FA-HA key is for. The COA in the > >>reg-request must be one of the FA's addresses but need not be the > >>address from which the FA forwards UDP reg requests to the HA. The > >>FQDN in FA-Host AVP might be a more reliable way to identify the FA > >>and store the key against. > >> > >>When a UDP MIP request containing a FA-HA auth ext is received, the HA > >>can get the host name of the FA from the source address (DNS) and > >>determine if it has a SA to that FA. Hopefully the address the FA uses > >>to forward the request matches against the hostname retrived from the > >>FA-Host AVP in the HAR. > >> > >>NOTE: If this usage, and thus the necessity of this AVP, makes sense, > >>maybe we can extend it as an argument for requiring support for the > >>GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg > >>requests will let the HA find a key for the FA (without using DNS) and > >>authenticate it. > >> > >>2. Section 1.3 in the MIP draft has text that says: > >> > >>"...it is necessary for the resulting HAR received by the HA to be > >>identified as a continuation of an existing session". > >> > >>Maybe the FQDN in the FA-Host-AVP is a reliable way to determine > >>session continuation?? > >> > >>thanks! > >> > >>Siva > >> > > > > > > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== From owner-aaa-wg@merit.edu Tue Apr 2 17:28:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05960 for ; Tue, 2 Apr 2002 17:28:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3211791273; Tue, 2 Apr 2002 17:28:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB50691274; Tue, 2 Apr 2002 17:28:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10A6E91273 for ; Tue, 2 Apr 2002 17:28:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id E693A5DDCA; Tue, 2 Apr 2002 17:28:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 842E15DDB1 for ; Tue, 2 Apr 2002 17:28:02 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g32MRri14177; Tue, 2 Apr 2002 16:27:53 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g32MRrS19016; Tue, 2 Apr 2002 16:27:53 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA07965; Tue, 2 Apr 2002 16:27:53 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA04592; Tue, 2 Apr 2002 16:27:52 -0600 (CST) Message-ID: <3CAA2FBB.6C1A3B53@ericsson.com> Date: Tue, 02 Apr 2002 14:24:59 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Joe Lau , AAA Working Group Subject: Re: [AAA-WG]: Issue 317:FA-HA Key References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Siva and All, What you explain below can not happen unless you have a broken implementation... You can not simply change the SPI value in the HA without also making sure that the FA gets the same SPI for the same key. With the clarification in section 4.5 below: change: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing keys with the HA, it MAY set the FA-HA-Key-Request flag". to: "If the FA's local policy allows it to receive AAA session Keys, and it does not have any existing FA-HA key with the HA, the FA MAY set the FA-HA-Key-Request flag" To me this is explicit enough, thus the FA may request one FA-HA key per session or use the same FA-HA key for multiple session, and since each FA-HA key has a unique SPI the FA and HA can easily identify which key to be use when authenticating the FA-HA auth extension in the MIP RRQ. However, I strongly believe how you choose to request and assign FA-HA keys is implementation specific and I don't think we need to say more then my suggested clarification above, and be done with this issue. What do others think? /Tony Sivasundar Ramamurthy wrote: > Hello Tony, > > On Mon, 1 Apr 2002, Tony Johansson wrote: > > > But each FA-HA key also has SPI, which helps out to identify the key. > > Thus, when a HA receives a MIP RRQ from the FA, the HA must identify the > > the right FA-HA key to be used by looking at the received FA-HA SPI in the > > FA-HA auth. > > What I think you are saying is that the HA maintains multiple HA-FA > keys (one for each session?), but can expect the FA to use any of > those keys. The HA authenticates the FA by selecting the key that > matches the SPI used by the FA, even if the key is from a different > session. And in order to make this work, the HA needs to make sure > that each session key has a unique SPI. > > This is different from the two implementations I was referring in my > original email: > > 1. The HA implementation maintains only one key to the FA. Everytime > it get a new key to the FA, it will refresh the existing key (if any) > and assign the same SPI to the new key. This is the only key that will > be used for all communication between the FA and HA. (corresponds to > "any key") > > > 2. The FA implementation maintains HA-FA key for each session, which > is the one and only key that can be used for any communication between > the FA and HA for that session -- the FA will expect the authenticator > from the HA to have been created only using that session's key (and > SPI). (corresponds to "session key"). > > I dont think there is anything in the draft that says that the above > two interpretations are wrong. Even if it may seem that "multiple > HA-FA keys indexed by SPI" is the correct way to do it, I feel that it > is better if we can make certain issues non-implementation specific to > eliminate chances of unnecessary HA-FA authentication failures. > > thanks, > > Siva > > > /Tony > > > > Sivasundar Ramamurthy wrote: > > > > > Hello Tony, > > > > > > On Mon, 1 Apr 2002, Tony Johansson wrote: > > > > > > > Why would it be interpretability problems ? > > > > > > If the HA and FA folllow different implementations, there might be > > > unnecessary authentication failures. Consider the case when the FA > > > keeps one FA-HA key per session, and the HA keeps one key per FA and > > > uses it for all sessions. If there are multiple MNs of that HA > > > visiting the FA, re-registrations of some MN's may result in in FA-HA > > > authentication failures -- FA is using the key from a specific > > > session, while the HA's "global" key to that FA is obtained from a HAR > > > from another session. > > > > > > Siva > > > > > > Thanks, > > Siva > > ==================================== > Sivasundar Ramamurthy > (She-va-su-ndar Ra-ma-moor-thee) > > Engineer, Mobile IP Project > Hewlett Packard > (408) 447 7255 > ==================================== From owner-aaa-wg@merit.edu Tue Apr 2 18:03:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07187 for ; Tue, 2 Apr 2002 18:03:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9806991272; Tue, 2 Apr 2002 18:03:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61CEB91274; Tue, 2 Apr 2002 18:03:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24E3191272 for ; Tue, 2 Apr 2002 18:03:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id F11515DDCA; Tue, 2 Apr 2002 18:03:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 9AA9D5DDB1 for ; Tue, 2 Apr 2002 18:03:07 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g32N37l25112; Tue, 2 Apr 2002 17:03:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g32N36B09876; Tue, 2 Apr 2002 17:03:06 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA11229; Tue, 2 Apr 2002 17:03:05 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA05219; Tue, 2 Apr 2002 17:03:04 -0600 (CST) Message-ID: <3CAA37FC.744CC4BF@ericsson.com> Date: Tue, 02 Apr 2002 15:00:12 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: Sivasundar Ramamurthy , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: <3CA8F54D.7167711E@ericsson.com> <3CA9C5D1.8000201@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm sorry if I was unclear in my previous mail. I meant to suggest that we keep the MIP-Foreign-Agent-Host AVP as optional in the HAR. What do others think? /Tony Johan Johansson wrote: > But I created this issue specifically because it is mandatory in HARs > and for some reason I can not even speculate about in HAAs. As for > Sivasundar's use for it I have been trying to find time to think it > through properly but not found it. I'll try to make some comments on it > though and then Sivasundar can correct my mistakes. > > The only text in the draft that touches this avp says that it is a copy > of the Origin-Host avp of the AMR. This means that you are keying your > SA on the diameter interface instead of the mobile ip tunneling > interface. I am not sure if it's a good idea to use something that is > invented by diameter to key the SA rather than something that the mobile > ip layer of the FA sends. > > A couple of weeks ago I went through the latest mobile ip draft together > with Fredrik to see if this split between the tunneling interface and > the control interface is supported in "raw" mobile ip. It doesn't seem > to be explicitly disallowed at any rate, but I am still not convinced > that it can in fact be made to work. In summary, if the FA-Host avp is > used you can use the diameter interface to key your SA and otherwise you > need to use the tunneling interface. Your thoughts on this Sivasundar? > > Regarding detecting session continuation on the clients: I suppose the > issue arises only for stateless clients? And for stateless clients you > are moving the detection to the mobile ip layer, right? > > j > > Tony Johansson wrote: > > >All, > > > >My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host > >AVP as is. After all it is only optional and it seems like some may find > >it useful. > > > >Comments / objections to this. > > > >/Tony > > > >Sivasundar Ramamurthy wrote: > > > >>Hello, > >> > >>I might have a couple of uses for this avp. > >> > >>1. The assumption here is that the FA-HA key is not session specific > >>(see Issue: 317). > >> > >>When the HAR containing the HA-FA key is received by the HA, the HA > >>needs to know which FA the FA-HA key is for. The COA in the > >>reg-request must be one of the FA's addresses but need not be the > >>address from which the FA forwards UDP reg requests to the HA. The > >>FQDN in FA-Host AVP might be a more reliable way to identify the FA > >>and store the key against. > >> > >>When a UDP MIP request containing a FA-HA auth ext is received, the HA > >>can get the host name of the FA from the source address (DNS) and > >>determine if it has a SA to that FA. Hopefully the address the FA uses > >>to forward the request matches against the hostname retrived from the > >>FA-Host AVP in the HAR. > >> > >>NOTE: If this usage, and thus the necessity of this AVP, makes sense, > >>maybe we can extend it as an argument for requiring support for the > >>GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg > >>requests will let the HA find a key for the FA (without using DNS) and > >>authenticate it. > >> > >>2. Section 1.3 in the MIP draft has text that says: > >> > >>"...it is necessary for the resulting HAR received by the HA to be > >>identified as a continuation of an existing session". > >> > >>Maybe the FQDN in the FA-Host-AVP is a reliable way to determine > >>session continuation?? > >> > >>thanks! > >> > >>Siva > >> > > From owner-aaa-wg@merit.edu Tue Apr 2 22:26:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13207 for ; Tue, 2 Apr 2002 22:26:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0729B9127B; Tue, 2 Apr 2002 22:26:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD2479127C; Tue, 2 Apr 2002 22:26:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 602069127B for ; Tue, 2 Apr 2002 22:26:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B9535DE05; Tue, 2 Apr 2002 22:26:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D68375DD8F for ; Tue, 2 Apr 2002 22:26:30 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g333QUi26402 for ; Tue, 2 Apr 2002 21:26:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g333QUK06942 for ; Tue, 2 Apr 2002 21:26:30 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA03417 for ; Tue, 2 Apr 2002 21:26:29 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA09051 for ; Tue, 2 Apr 2002 21:26:28 -0600 (CST) Message-ID: <3CAA75B7.9D3A2F2@ericsson.com> Date: Tue, 02 Apr 2002 19:23:35 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: <3CA8D130.509970A7@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here are some clarifications/changes to some editorial mistakes in the proposed text that I sent out yesterday regarding issue#299 and #301. Please find the clarifications/changes made embedded... /Tony Tony Johansson wrote: > I'm sorry if you receive this twice.... > > /Tony > > -------- Original Message -------- > Subject: Issue #299 and #301 Date: Mon, 01 Apr 2002 11:53:07 -0800 From: Tony Johansson To: aaa-wg@merit.edu > > All, > > I have worked on new proposed text for issue 299 and 301, see below, > based on the solution we agree upon at the IETF 53. Part of this > solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines > the needed AAAH NAI and the HA NAI, please see > http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt. > The draft have been submitted to the mobileip wg and will go to wg > final call if no major comments/issues are found on the mobileip wg > list. > > I hope this solves the issue 299 and 301, however I need help to > understand how I should deal the newly submitted issue #321 regarding > CMS. Is it good enough to just move the CMS ref to informative? > > Comments please. > > /Tony > > > > > > Added to to section 1.0: > > "1.0 Introduction > > ... > > Furthermore, the nature of mobile IP also means that the mobile > node > will do handoffs between different foreign agents and to guarantee > that a registered user always ends up in the same initial AAAH the > Mobile Node MUST always include the home NAI and the AAAH NAI > [AAANAI]. change to: Furthermore, the nature of mobile IP also means that the mobile node will do handoffs between different foreign agents and to guarantee that a registered user always ends up in the same initial AAAH the Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the messages to a mobile node's home agent the mobile node MUST always include the HA NAI [AAANAI]. > > > ... " > > I've made changes here and there in section 1.2, 1.3 and 1.4, so here > is the whole text... > > " 1.2 Inter-Realm Mobile IP > > When a Mobile Node node requests service by issuing a Registration > Request to the foreign agent, the foreign agent creates the AA- > Mobile-Node-Request (AMR) message, which includes the AVPs defined > in > section 2.1. The Home Address, Home Agent, Mobile Node NAI and > other > important fields are extracted from the registration messages for > possible inclusion as Diameter AVPs. The AMR message is then > forwarded to the local Diameter server, known as the AAA-Foreign, > or > AAAF. > > Visited Realm Home Realm > +--------+ +--------+ > |abc.com | AMR/AMA |xyz.com | > | AAAF |<------------------->| AAAH | > +->| server | server-server | server | > | +--------+ communication +--------+ > | ^ ^ > | AMR/AMA | client-server | HAR/HAA > | | communication | > v v v > +---------+ +---------+ +---------+ > | Foreign | | Foreign | | Home | > | Agent | | Agent | | Agent | > +---------+ +---------+ +---------+ > ^ > | Mobile IP > | > v > +--------+ > | Mobile | > | Node | mn@xyz.com > +--------+ > Figure 1: Inter-Realm Mobility > > Upon receiving the AMR, the AAAF follows the procedures outlined in > > [DIAMBASE] to determine whether the AMR should be processed > locally, > or if it should be forwarded to another Diameter server, known as > the > AAA-Home, or AAAH. Figure 1 shows an example in which a mobile > node > (mn@xyz.com) requests service from a foreign provider (abc.com). > The > request received by the AAAF is forwarded to xyz.com's AAAH server. > > Figure 2 shows the message flows involved when the foreign agent > invokes the AAA infrastructure to request that a mobile node be > authenticated and authorized. Note that it is not required that the > > foreign agent invoke AAA services every time a Registration Request > > is received from the mobile, but rather only when the prior > authorization from the AAAH expires. The expiration time of the > authorization is communicated through the Authorization-Lifetime > AVP > in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. > > Mobile Node Foreign Agent AAAF AAAH Home > Agent > ----------- ------------- ------------ ---------- > ---------- > Advertisement & > <--------- Challenge > > Reg-Req&MN-AAA ----> > > AMR------------> > Session-Id = foo > > AMR------------> > Session-Id = foo > > HAR-----------> > Session-Id = bar > > <----------HAA > Session-Id = bar > > <-----------AMA > Session-Id = foo > > <------------AMA > Session-Id = foo > > <-------Reg-Reply > > Figure 2: Mobile IP/Diameter Message Exchange > > The foreign agent (as shown in Figure 2) MAY provide a challenge, > which gives it direct control over the replay protection in the > Mobile IP registration process, as described in [MIPCHAL]. The > mobile node includes the Challenge and MN-AAA authentication > extension to enable authorization by AAAH. If the authentication > data > supplied in the MN-AAA extension is invalid, AAAH returns the > response (AMA) with the Result-Code AVP set to > DIAMETER_AUTHENTICATION_REJECTED. > > A mobile node, which has been previously authenticated > andauthorized, > MUST always include the assigned home agent in the HA-NAI > and the authorizing Home AAA server in the AAAH-NAI in the > registration request message [AAANAI] sent to the FA, every time > the > Mobile Node needs to re-authenticating. So, in the event that the > AMR > generated by the FA is for a session that has was previously > authorized, it MUST include the Destination-Host AVP, with the > identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- > Host AVP the identity of the assigned HA found in the HA-NAI. change to: A mobile node, which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA-NAI and the authorizing Home AAA server in the AAAH-NAI in the registration request message [AAANAI] sent to the FA, every time the Mobile Node needs to be re-authenticated. So, in the event that the AMR generated by the FA is for a session that has was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- Host AVP the identity of the assigned HA found in the HA-NAI. > > > If the mobile node was successfully authenticated, the AAAH checks > if > the Home Agent was located in the foreign realm, by checking the > MIP- > Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. > If > home agent is located in the foreign realm, then AAAH sends an HAR > message to the home agent, which contains a MIP-Reg-Request AVP. > > If the home agent was not located in the foreign realm, the AAAH > checks for the MIP-Home-Agent-Address AVP and if present the MIP- > Home-Agent-Host AVP. If one was specified, the AAAH checks that the > > address is that of a known home agent and that the Mobile Node is > allowed to request this particular home agent, and that the home > agent's identity is included in the MIP-Home-Agent-Host AVP. If no > home agent was specified, and if the MIP-Feature-Vector has the > Home- > Agent-Requested flag set, and if allowed by policy in the home > realm, > the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. > > This can be done in a variety of ways, including using a load > balancing algorithm in order to keep the load on all home agents > equal. The actual algorithm used and the method of discovering the > home agents is outside the scope of this specification. > > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains > > the Mobile IP Registration Request message data encapsulated in the > > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The > AAAH MAY allocate a home address for the mobile node, while the > Home > Agent MUST support home address allocation. In the event the AAAH > handles address allocation, it includes it in a MIP-Mobile-Node- > Address AVP within the HAR. The absence of this AVP informs the > Home > Agent to perform the allocation. > > During the creation of the HAR, the AAAH MUST use a different > session > identifier than the one used in the AMR/AMA (see Figure 2). If the > AAAH is session-stateful, it MUST send the same session identifier > for all HARs initiated on behalf of a given mobile node's session. > Otherwise, if the AAAH is session-stateless, it will manufacture a > unique session-id for every HAR. > > A mobile node's session is identified via its identity in the User- > Name AVP, the MIP-Mobile-Node-Address and the > MIP-Home-Agent-Address > AVPs. This is necessary in order to allow the session state > machine, > defined in the base protocol [DIAMBASE], to be used unmodified with > > this application. Therefore, an STR from a foreign agent would free > > the session from the foreign agent, but not the one towards the > home > agent (see figure 3). > > STR, Session-Id = foo STR, Session-Id = bar > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > STA, Session-Id = foo STA, Session-Id = bar > Figure 3: Session Termination and Session Identifiers > > Upon receipt of the HAR, the home agent first processes the > Diameter > message. The home agent processes the MIP-Reg-Request AVP and > creates > the Registration Reply, encapsulating it within the MIP-Reg-Reply > AVP. In the creation of the Registration Reply the Home Agent must > include the HA NAI and the AAAH NAI, which will be created from the > > Originating-Host AVP and Originating-Realm AVP of the HAR. If a > home > address is needed, the home agent MUST also assign one and include > the address in both the Registration Reply and within the > MIP-Mobile- > Node-Address AVP. > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > returned to the AAAH. > > Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > > (AMA) message, includes the Accounting-Multi-Session-Id that was > present in the HAA, and the MIP-Home-Agent-Address, > MIP-Mobile-Node- > Address AVPs in the AMA message, enabling appropriate firewall > controls for the penetration of tunneled traffic between the Home > Agent and the Mobile Node. > > The AAAF is responsible for ensuring that the AMA message is > properly > forwarded to the correct foreign agent. > > > 1.3 Support for Mobile IP Handoffs > > Given the nature of Mobile IP, a mobile node MAY receive service > from > many foreign agents during a period of time. However, the home > realm > should not view these handoffs as different sessions, since this > could affect billing systems. Furthermore, many foreign agents do > not > communicate, which makes it quite difficult for AAA information to > be > exchanged between these entities. Therefore, it MUST be assumed > that > a foreign agent is not aware that a registration request from a > mobile node has been previously authorized. > > The first registration request from a mobile node will therefore > cause an AMR to be sent to its AAAF. The AMR will include a new > session identifier, and MAY even be sent to a different AAAF in the > > visited network. change to: The first registration request from a mobile node will therefore cause an AMR to be sent to its AAAF. The AMR will include a new session identifier, and MAY even be sent to a different AAAF in the visited network. However, with the usage of the AAA NAI, this AMR is guaranteed to be received by the AAAH to which the user is currently registered. > > > Since the AAAH may be session-stateless, it is necessary for the > resulting HAR received by the HA to be identified as a continuation > > of an existing session. If the HA receives an HAR for a mobile > node, > with a new session identifier, and the HA can guarantee that this > request is to extend service for an existing service, then the HA > MUST be able to modify its internal session state information to > reflect the new session identifier. > > It is necessary for accounting records to have some commonality > across handoffs in order for correlation to occur. Therefore, the > home agent MUST send the same Accounting-Multi-Session-Id AVP value > > in all HAAs for the mobile's session. That is, the HA generates a > unique Accounting-Multi-Session-Id when receiving an HAR for a new > session, and returns this same value in every HAA for the session. > This Accounting-Multi-Session-Id AVP will be returned to the > foreign > agent by the AAAH in the AMA. Both the foreign and home agents MUST > > include the Accounting-Multi-Session-Id in the accounting messages. > > ACR, Session-Id = foo ACR, Session-Id = bar > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = > a > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > > > 1.4 Allocation of Home Agent in Foreign Network > > The Diameter Mobile IP application allows a home agent to be > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > When a foreign agent detects that the mobile node has a home agent > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > Request message, it MUST add a MIP-Feature-Vector AVP with the > Home- > Agent- Requested flag set to one. If the home agent address is > equal > to 255.255.255.255, then the foreign agent also MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the > home > agent address is set to 0.0.0.0, the foreign agent MUST set the > Home- > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the Home-Agent-Requested > > flag set to one, and the > Home-Address-Allocatable-Only-in-Home-Realm > flag equal to zero, the AAAF MAY set the > Foreign-Home-Agent-Available > flag in the MIP-Feature-Vector AVP to inform the AAAH that it is > willing and able to assign a Home Agent for the Mobile Node. When > doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host > AVP > and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- > Agent-Host AVP contains the identity of the home agent that would > be > assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > > contains the identity of the AAAF. > > In the event that the mobile node has been previously authorized by > > the AAAH and now needs to be re-authenticated, and requests to keep > > the assigned home agent in the foreign network, the mobile node > MUST > include the HA NAI and the AAAH NAI in the registration request to > the FA. Upon receipt, the FA will in create the AMR including the > MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the > AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP > include > the MIP-Home-Agent-Host AVP based on the home agent NAI. If the > AAAF > authorizes the use of the requested home agent, the AAAF MUST set > the > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > When the AAAH receives an AMR message, it first checks the > authentication data supplied by the mobile node, according to the > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > > to authorize the mobile node. If the AMR indicates that the AAAF > has > offered to allocate a Home Agent for the mobile node, i.e. the > Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, > or > the AMR indicates that the AAAF has offered a previously allocated > Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- > Network is set in the MIP-Feature-Vector AVP, then the AAAH must > decide whether its local policy would allow the user to have a Home > > Agent in the foreign network or to keep the Home Agent in the > foreign > network. If so, and after checking authorization from the data in > the > AMR message, the AAAH sends the HAR message to Home Agent > byincluding > the Destination-Host AVP set to the value found in the > AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP > if > the HA has been previously allocated and authorized by the AAAH. If > > the HA has not been previously allocated by the foreign domain, the > > HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. > > The HAR sent by the AAAH back to the foreign realm with the > Destination-Host AVP set to the home agents identity, may not > necessarily be received by the same AAAF, which sent the AMR. > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA > > AVP from the AMR message to the HAR message. In cases when another > AAAF receives the HAR, the new AAAF will use the MIP-Originating- > Foreign-AAA AVP for policy decisions, such as determining if the > FA- > HA Key should be encrypted or not. If on the other hand, the AAAH > local policy determines that the MN-HA Key and the MN-FA Key must > be > encrypted and no security association is known to the home agent, > the > AAAH SHOULD send the HAR to the originating AAAF by including the > Destination-Host AVP set to the value found in the AMR's MIP- > Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or > > the MIP-Candidate-Home-Agent-Host AVP found in the AMR. > > Visited Home > Realm Realm > +--------+ ------- AMR -------> +--------+ > | AAAF | <------ HAR -------- | AAAH | > | | | | > +--->| server | ------- HAA -------> | server | > | +--------+ <------ AMA -------- +--------+ > | ^ | > | | | > HAR/HAA | AMR | | AMA > v | v > +---------+ +---------+ > | Home | | Foreign | > | Agent | | Agent | > +---------+ +---------+ > ^ > +--------+ | > | Mobile |<----------+ > | Node | Mobile IP > +--------+ > Figure 5: Home Agent allocated in Visited Realm > > Upon receipt of a HAA from the Home Agent in the visited realm, the > > AAAF forwards the HAA to the AAAH in the home realm. The AMA is > then > constructed, and issued to the AAAF, and finally to the FA. If the > Result-Code indicates success, the HAA and AMA MUST include the > MIP- > Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > > Mobile Node Foreign Agent Home Agent AAAF AAAH > ----------- ------------- ------------- ---------- > ---------- > > <----Challenge---- > Reg-Req (Response)-> > ------------AMR-------------> > -----AMR----> > <----HAR----- > <-----HAR------ > ------HAA------> > -----HAA----> > <----AMA----- > <-------------AMA------------ > <---Reg-Reply---- > Figure 6: Mobile IP/Diameter Message Exchange > > If the Mobile Node moves to another Foreign Network, it MAY either > request to keep the same Home Agent within the old foreign network, > > or request to get a new one in the new foreign network. If the AAAH > > is willing to provide the requested service, the mobile node will > have to interact with two AAAFs. Change to: If the Mobile Node moves to another Foreign Network, it MAY either request to keep the same Home Agent within the old foreign network, or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the mobile node will have to be serviced by two AAAFs. > > > Figure 7 shows the message flows for a Mobile Node requesting to > keep > the Home Agent assigned in Foreign network 1 when it moves to > foreign > network 2. Upon reception of the AMR in Foreign network 2, the AAAF > > follows the procedures described earlier and forwards AMR to the > Mobile Node's home network, i.e. its AAAH. If the Mobile Node was > successfully authenticated, the AAAH checks the identity of the > foreign and home agent to determine whether the user is in a third > realm. If this is the case, the AAAH must check whether the mobile > is > still permitted to use the previously assigned Home Agent. > > +---------------+ +---------------+ +-------------+ > > |Foreign net 2 | |Foreign net 1 | |Home network | > > | | | | | | > > Mobile Node | FA AAAF | | HA AAAF | | AAAH | > > ----------- | ---- ---- | | ---- ------ | | ------ | > > +---------------+ +---------------+ +-------------+ > > <----Challenge---- > Reg-Req (Response)-> > ---AMR---> > ----------------AMR---------------> > <-----HAR----- > <---HAR---- > ----HAA---> > ------HAA----> > <---------------AMA---------------- > <--AMA---- > <----Reg-Reply----- > Figure 7: Request to access Home Agent from new Foreign Network > > If the mobile node is allowed to keep the home agent the AAAH then > sends a HAR, which contains the Mobile IP Registration Request > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > Home-Agent-Address AVP with home agent address, as well as any > optional KDC session keys, to the AAAF in foreign network 1. > Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA > AVP from AMR and include it in the HAR when a third foreign domain > is > involved, since the AAAF will use the MIP-Originating-Foreign-AAA > AVP > for policy decisions, such as determining if the FA-HA Key should > be > encrypted or not. Upon reception the AAAF in foreign network 1 will > > forward the HAR to the Home Agent if its local policy allows such > service. If the AAAF does not permit such service, it MUST return a > > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > If the AAAH local policy determines that the MN-HA Key must be > encrypted and no security association is known to the home agent, > the > AAAH MUST send the HAR to the AAAF in foreign network 1, which > originally assigned the HA in foreign network 1, by including its > identity in the Destination-Host AVP. > > When the AAAF receives a HAA, the AAAF will forward the HAA back to > > the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- > Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then > send > back an AMA to the AAAF in foreign network 2. > > If the old Foreign Network does not permit the use of its Home > Agent > when the Mobile Node moves to a new foreign network, the AAAH or > AAAF > MUST return an AMA with the Result-Code AVP set to > DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the > Foreign Agent MUST issue a Mobile IP Registration Reply to the > Mobile > Node with an appropriate error. The Mobile Node MAY attempt to > request that a new Home Agent and Address be allocated. When the > AAAH > transmits such an error, it MUST issue a Diameter Abort-Session- > Request message to the Home Agent to enable it to release any > resources. " > > Added to section 2.1 AA-Mobile-Node-Request: > > "2.1 AA-Mobile-Node-Request > > The AA-Mobile-Node-Request (AMR), indicated by the Command-Code > field > set to 260 and the 'R' bit set in the Command Flags field, is sent > by > an attendant, acting as a Diameter client, to a server in order to > request the authentication and authorization of a Mobile Node. The > > Foreign Agent (or Home Agent in the case of a co-located Mobile > Node) > uses information found in the Registration Request to construct the > > following AVPs that are to be included as part of the AMR: > > ... > home agent NAI (MIP-Home-Agent-Host AVP) > home AAA server NAI (Destination-Host AVP [DIAMBASE]) > > > ... > > If the mobile node includes the home agent NAI and the home AAA > server NAI [AAANAI], the foreign agent MUST include the MIP-Home- > Agent-Host AVP and the Destination-Host AVP in the AMR. > > ..." > > Added to section 4.0: > > " > MIP-Home-Agent 348 4.12 Grouped | M | P | | V | Y > | > Host | | | | | > | " > > > > Added a new grouped AVP: > > "4.12 MIP-Home-Agent-Host AVP > > The MIP-Home-Agent-Host AVP (AVP Code TBD)if of type Grouped, > and contains the identity of the assigned Home Agent. > If present in the AMR, the AAAH MUST copy the MIP-Home-Agent-Host > AVP into the HAR. > > MIP-Home-Agent-Host ::= < AVP Header: 348 > > { Destination-Realm } > { Destination-Host } > * [ AVP ] " > > Added new text to section 5.3 : > > " 5.3 Distributing the Mobile-Home Session Key > > ... > > If the home agent is in the home realm, then AAAH can directly > encode > the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include > > that AVP in the HAR message for delivery to the home agent. > > If, on the other hand, the home agent is to be allocated in the > visited realm, the AAAH transmits the HAR to the foreign home > agent, > where, prior to delivery to the home agent, it is perused by the > AAAF > hosting the home agent. If the session key needs to be encrypted > the > AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data > AVP using the security association with the home agent or with the > AAAF associated with the home agent. If no security association is > known the home agent, the AAAH will check if a security association > > can be established using DSA messages defined in the CMS > application > [CMS] with the originating host found in the > MIP-Originating-Foreign- > AAA AVP and if the DSA establishment is successful, the AAAH will > encrypt the MIP-HA-to-MN Key AVP with the established security > association. On the other hand, if no security association exists > and > the DSA establishment fails, the AAAH MUST return a Result-Code AVP > > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > ... " > > > > > > From owner-aaa-wg@merit.edu Wed Apr 3 03:48:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27403 for ; Wed, 3 Apr 2002 03:48:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 192989127F; Wed, 3 Apr 2002 03:48:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D90BA91280; Wed, 3 Apr 2002 03:48:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEB0D9127F for ; Wed, 3 Apr 2002 03:48:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id A55455DDD3; Wed, 3 Apr 2002 03:48:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 029355DD8E for ; Wed, 3 Apr 2002 03:48:40 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g338caF19446; Wed, 3 Apr 2002 10:38:36 +0200 Message-ID: <3CAABF65.4020000@ipunplugged.com> Date: Wed, 03 Apr 2002 10:37:57 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Sivasundar Ramamurthy , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: <3CA8F54D.7167711E@ericsson.com> <3CA9C5D1.8000201@ipunplugged.com> <3CAA37FC.744CC4BF@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fine by me. I don't have a vendetta against the FA avp. I was merely confused to why an avp whose use is never described was mandatory. j Tony Johansson wrote: >I'm sorry if I was unclear in my previous mail. I meant to suggest that we >keep the MIP-Foreign-Agent-Host AVP as optional in the HAR. > >What do others think? > >/Tony > >Johan Johansson wrote: > >>But I created this issue specifically because it is mandatory in HARs >>and for some reason I can not even speculate about in HAAs. As for >>Sivasundar's use for it I have been trying to find time to think it >>through properly but not found it. I'll try to make some comments on it >>though and then Sivasundar can correct my mistakes. >> >>The only text in the draft that touches this avp says that it is a copy >>of the Origin-Host avp of the AMR. This means that you are keying your >>SA on the diameter interface instead of the mobile ip tunneling >>interface. I am not sure if it's a good idea to use something that is >>invented by diameter to key the SA rather than something that the mobile >>ip layer of the FA sends. >> >>A couple of weeks ago I went through the latest mobile ip draft together >>with Fredrik to see if this split between the tunneling interface and >>the control interface is supported in "raw" mobile ip. It doesn't seem >>to be explicitly disallowed at any rate, but I am still not convinced >>that it can in fact be made to work. In summary, if the FA-Host avp is >>used you can use the diameter interface to key your SA and otherwise you >>need to use the tunneling interface. Your thoughts on this Sivasundar? >> >>Regarding detecting session continuation on the clients: I suppose the >>issue arises only for stateless clients? And for stateless clients you >>are moving the detection to the mobile ip layer, right? >> >>j >> >>Tony Johansson wrote: >> >>>All, >>> >>>My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host >>>AVP as is. After all it is only optional and it seems like some may find >>>it useful. >>> >>>Comments / objections to this. >>> >>>/Tony >>> >>>Sivasundar Ramamurthy wrote: >>> >>>>Hello, >>>> >>>>I might have a couple of uses for this avp. >>>> >>>>1. The assumption here is that the FA-HA key is not session specific >>>>(see Issue: 317). >>>> >>>>When the HAR containing the HA-FA key is received by the HA, the HA >>>>needs to know which FA the FA-HA key is for. The COA in the >>>>reg-request must be one of the FA's addresses but need not be the >>>>address from which the FA forwards UDP reg requests to the HA. The >>>>FQDN in FA-Host AVP might be a more reliable way to identify the FA >>>>and store the key against. >>>> >>>>When a UDP MIP request containing a FA-HA auth ext is received, the HA >>>>can get the host name of the FA from the source address (DNS) and >>>>determine if it has a SA to that FA. Hopefully the address the FA uses >>>>to forward the request matches against the hostname retrived from the >>>>FA-Host AVP in the HAR. >>>> >>>>NOTE: If this usage, and thus the necessity of this AVP, makes sense, >>>>maybe we can extend it as an argument for requiring support for the >>>>GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg >>>>requests will let the HA find a key for the FA (without using DNS) and >>>>authenticate it. >>>> >>>>2. Section 1.3 in the MIP draft has text that says: >>>> >>>>"...it is necessary for the resulting HAR received by the HA to be >>>>identified as a continuation of an existing session". >>>> >>>>Maybe the FQDN in the FA-Host-AVP is a reliable way to determine >>>>session continuation?? >>>> >>>>thanks! >>>> >>>>Siva >>>> > From owner-aaa-wg@merit.edu Wed Apr 3 05:44:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28882 for ; Wed, 3 Apr 2002 05:44:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABFEA91205; Wed, 3 Apr 2002 05:41:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FC1791280; Wed, 3 Apr 2002 05:41:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36C2A91205 for ; Wed, 3 Apr 2002 05:41:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16F7B5DE24; Wed, 3 Apr 2002 05:41:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 33C195DD8E for ; Wed, 3 Apr 2002 05:41:16 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g33ATv320226; Wed, 3 Apr 2002 12:30:01 +0200 Message-ID: <3CAAD97C.9000906@ipunplugged.com> Date: Wed, 03 Apr 2002 12:29:16 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Tony Johansson , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sivasundar Ramamurthy wrote: >> >>The only text in the draft that touches this avp says that it is a copy >>of the Origin-Host avp of the AMR. This means that you are keying your >>SA on the diameter interface instead of the mobile ip tunneling >>interface. I am not sure if it's a good idea to use something that is >>invented by diameter to key the SA rather than something that the mobile >>ip layer of the FA sends. >> > >but does not the Origin-Host contain the FQDN of the FA? My >assumption is that a DNS lookup on this FQDN might give us all the >control addresses used by the FA. > Yes, it contains a DiameterIdentity that is defined to be an FQDN. First of all I am not sure you could get all the ip addresses using DNS, but assuming for the moment that you could, I guess it would work to try an SA-lookup on all of them and use the first that matches. I suppose the FQDN might legally resolve to more than one ip address even when used as a DiameterIdentity, but there is nothing that says that this would include the interface(s) used for mobile ip traffic, control or otherwise. >>A couple of weeks ago I went through the latest mobile ip draft together >>with Fredrik to see if this split between the tunneling interface and >>the control interface is supported in "raw" mobile ip. It doesn't seem >>to be explicitly disallowed at any rate, but I am still not convinced >>that it can in fact be made to work. >> > >Cant this happen when the "r" bit is set on the agent adv and the MN >is using a co-located COA? Or if the advertised COA and the >the control interface are different? > Revisiting this today we reached the conclusion that this is in fact a serious error either in Diameter or MobileIP. The home agent can not know which ip address to key the SA on. We agree that it is possible for an FA to send the Diameter control traffic on one interface, the MobileIP control traffic on a second interface and the MobilIP tunnel traffic on a third interface. In raw mobile ip the preshared keys are hopefully stored using the right ip address, but when the HA receives a dynamically generated key it must know which ip address to store it under. Your example with the R bit is also a good one. You would probably be guaranteed that the source address in the UDP packet differs from the one used for the actual traffic, with the possible exclusion of when using NATed addresses. In any case, the HA does not know which ip address to use for it's SA with the FA. Note that this means that any implementation that assumes that it knows how to key the SA is *severly broken*. I can see 3 different solutions to this problem. 1. Make the MIP-Foreign-Agent-Host avp a MIP-Foreign-Agent-Address avp and make it mandatory in the AMR and HAR. 2. Since the UDP header is part of the MobileIP protocol, include the UDP header in the MIP-Reg-Request avp 3. Demand that the CoA is used to key SAs in MobileIP (fat chance - but it is a possible solution) >>Regarding detecting session continuation on the clients: I suppose the >>issue arises only for stateless clients? And for stateless clients you >>are moving the detection to the mobile ip layer, right? >> > >but I was referring to the support for Handoff issues in Diameter MIP >draft section 1.3. Using the FA-Host-AVP, the HA can determine if the >MN has moved to a new realm or a different FA in the same realm. My >understanding is that the HA maintains MN session per Realm, not per >FA. But do remember that this particular usage of the AVP is a guess >of mine.. :-) > No. It cannot know if fa1.fluffybunny.nowhere.net and fa7.pinkelephant.nowhere.net are in the same realm or not. It only knows that they are different FAs. It is also my understanding that the HA maintains per MN sessions, not per FA or per realm. It would in other words be an error for a handover between two different realms to be two different sessions on the HA with different accounting multi session ids. j From owner-aaa-wg@merit.edu Wed Apr 3 07:44:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01160 for ; Wed, 3 Apr 2002 07:44:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2291F91221; Wed, 3 Apr 2002 07:44:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D518191222; Wed, 3 Apr 2002 07:44:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8737B91221 for ; Wed, 3 Apr 2002 07:44:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64E625DDB8; Wed, 3 Apr 2002 07:44:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C04275DDAD for ; Wed, 3 Apr 2002 07:44:16 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g33CiU507912 for ; Wed, 3 Apr 2002 15:44:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 3 Apr 2002 15:44:14 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 15:44:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1DB0D.42EDBAE8" Subject: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Wed, 3 Apr 2002 15:44:14 +0300 Message-ID: <93532512B06FC3489824C18037DB3D4B7B75C6@esebe015.NOE.Nokia.com> X-MS-Has-Attach: yes Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbDUK6KA2GhEbLEdaqaAACswWDNA== From: To: Cc: X-OriginalArrivalTime: 03 Apr 2002 12:44:15.0011 (UTC) FILETIME=[431CE730:01C1DB0D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DB0D.42EDBAE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <<[AAA-WG]: Re: Bug in Acct state machine>>=20 Hi, With regard to the attached proposed accounting session state machine = for client and server, at least the following would require some = consideration: Server Accounting: All the states proposed for Server Accounting are Idle (check the = diamstates.txt).How is that possible? Shouldn't at least Open and Idle be required/ needed for the server side = ? Also, in previous email with regard to the same topic some additional = state-event transitions in particular Interim Record was presented which = is not included in the diamstates.txt . Thanks & Regards Elena Lialiamou ------_=_NextPart_001_01C1DB0D.42EDBAE8 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1D988.14C02180" Subject: [AAA-WG]: Re: Bug in Acct state machine Date: Mon, 1 Apr 2002 14:51:41 +0300 Message-ID: <3CA849CD.1040208@kolumbus.fi> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Re: Bug in Acct state machine Thread-Index: AcHZiBVpmLRsP8EWSN+SJlCwtNue2w== From: To: , This is a multi-part message in MIME format. ------_=_NextPart_002_01C1D988.14C02180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > >Shouldn't the above be: > > Discon ASR Received Send STA. Discon >=20 > Not quite. The STA is sent by the server, not the client. >=20 > There is an issue, however, on what to do if we have already sent an = STR, > are waiting for the STA to arrive but then we get an ASR from the = server > (STR and ASR meet on the wire). The -09 state machine simply ignored = the > ASR in this case, and on the server side was able to terminate the = session > if, while waiting for ASA would instead get STR. I think Pete's state > machine gets it right as well. On second thought, and on reading section 8.5, it seems that the more appropriate action is really answering the ASR also. The ASR could come from some other server than the one we sent the STR to. So, if we are in the progress of releasing the session already and we get ASR, we should respond with ASA Result-Code =3D Success. Modified state machine attached. Jari ------_=_NextPart_002_01C1D988.14C02180 Content-Type: text/plain; name="diamstates.txt" Content-Description: diamstates.txt Content-Disposition: inline; filename="diamstates.txt" Content-Transfer-Encoding: base64 DQo4LjEgIEF1dGhvcml6YXRpb24gU2Vzc2lvbiBTdGF0ZSBNYWNoaW5lDQoNCiAgIFRoaXMgc2Vj dGlvbiBjb250YWlucyBhIHNldCBvZiBmaW5pdGUgc3RhdGUgbWFjaGluZXMsIHJlcHJlc2VudGlu ZyB0aGUgbGlmZQ0KICAgY3ljbGUgb2YgRGlhbWV0ZXIgc2Vzc2lvbnMsIGFuZCB3aGljaCBNVVNU IGJlIG9ic2VydmVkIGJ5IGFsbCBEaWFtZXRlcg0KICAgaW1wbGVtZW50YXRpb25zIHRoYXQgbWFr ZSB1c2Ugb2YgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZC9vcg0KICAgYXV0aG9yaXphdGlvbiBwb3J0 aW9uIG9mIGEgRGlhbWV0ZXIgYXBwbGljYXRpb24uIFRoZSB0ZXJtIFNlcnZpY2UtDQogICBTcGVj aWZpYyBiZWxvdyByZWZlcnMgdG8gYSBtZXNzYWdlIGRlZmluZWQgaW4gYSBEaWFtZXRlciBhcHBs aWNhdGlvbg0KICAgKGUuZy4gTW9iaWxlIElQLCBOQVNSRVEpLg0KDQogICBUaGVyZSBhcmUgZm91 ciBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBzZXNzaW9uIHN0YXRlIG1hY2hpbmVzDQogICBzdXBw b3J0ZWQgaW4gdGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wuIFRoZSBmaXJzdCB0d28gZGVzY3Jp YmUgYQ0KICAgc2Vzc2lvbiBpbiB3aGljaCB0aGUgc2VydmVyIGlzIG1haW50YWluaW5nIHNlc3Np b24gc3RhdGUsIGluZGljYXRlZA0KICAgYnkgdGhlIHZhbHVlIG9mIHRoZSBBdXRoLVNlc3Npb24t U3RhdGUgQVZQIChvciBpdHMgYWJzZW5jZSkuICBPbmUNCiAgIGRlc2NyaWJlcyB0aGUgc2Vzc2lv biBmcm9tIGEgY2xpZW50IHBlcnNwZWN0aXZlLCB0aGUgb3RoZXIgZnJvbSBhDQogICBzZXJ2ZXIg cGVyc3BlY3RpdmUuIFRoZSBzZWNvbmQgdHdvIHN0YXRlIG1hY2hpbmVzIGFyZSB1c2VkIHdoZW4N CiAgIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbWFpbnRhaW4gc2Vzc2lvbiBzdGF0ZS4gSGVyZSBhZ2Fp biwgb25lDQogICBkZXNjcmliZXMgdGhlIHNlc3Npb24gZnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2 ZSwgdGhlIG90aGVyIGZyb20gYQ0KICAgc2VydmVyIHBlcnNwZWN0aXZlLg0KDQogICBXaGVuIGEg c2Vzc2lvbiBpcyBtb3ZlZCB0byB0aGUgSWRsZSBzdGF0ZSwgYW55IHJlc291cmNlcyB0aGF0IHdl cmUNCiAgIGFsbG9jYXRlZCBmb3IgdGhlIHBhcnRpY3VsYXIgc2Vzc2lvbiBtdXN0IGJlIHJlbGVh c2VkLiAgQW55IGV2ZW50IG5vdA0KICAgbGlzdGVkIGluIHRoZSBzdGF0ZSBtYWNoaW5lcyBNVVNU IGJlIGNvbnNpZGVyZWQgYXMgYW4gZXJyb3INCiAgIGNvbmRpdGlvbiwgYW5kIGFuIGFuc3dlciwg aWYgYXBwbGljYWJsZSwgTVVTVCBiZSByZXR1cm5lZCB0byB0aGUNCiAgIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFjaGluZSBpcyBvYnNlcnZl ZCBieSBhIGNsaWVudCB3aGVuIHN0YXRlIGlzDQogICBtYWludGFpbmVkIG9uIHRoZSBzZXJ2ZXI6 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENMSUVOVCwgU1RBVEVGVUwNCiAgICAg IFN0YXRlICAgICBFdmVudCAgICAgICAgICAgICAgICAgICAgICAgICAgQWN0aW9uICAgICBOZXcg U3RhdGUNCiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIElkbGUgICAgICBDbGllbnQgb3IgRGV2aWNlIFJlcXVl c3RzICAgICAgU2VuZCAgICAgICBQZW5kaW5nDQogICAgICAgICAgICAgICAgYWNjZXNzICAgICAg ICAgICAgICAgICAgICAgICAgIHNlcnZpY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYXV0aCByZXENCg0KICAgICAgSWRsZSAgICAgIEFTUiBSZWNlaXZl ZCAgICAgICAgICAgICAgICAgICBTZW5kIEFTQSAgIElkbGUNCiAgICAgICAgICAgICAgICBmb3Ig dW5rbm93biBzZXNzaW9uICAgICAgICAgICAgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSZXN1bHQtQ29kZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IFVOS05PV04tDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNFU1NJT04tSUQNCg0KICAgICAgUGVuZGluZyAg IFN1Y2Nlc3NmdWwgU2VydmljZS1zcGVjaWZpYyAgICBHcmFudCAgICAgIE9wZW4NCiAgICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAgICAgQWNjZXNzDQogICAgICAgICAg ICAgICAgcmVjZWl2ZWQgd2l0aCBkZWZhdWx0DQogICAgICAgICAgICAgICAgQXV0aC1TZXNzaW9u LVN0YXRlIHZhbHVlDQoNCiAgICAgIFBlbmRpbmcgICBTdWNjZXNzZnVsIFNlcnZpY2Utc3BlY2lm aWMgICAgU2VudCBTVFIgICBEaXNjb24NCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGFu c3dlciByZWNlaXZlZA0KICAgICAgICAgICAgICAgIGJ1dCBzZXJ2aWNlIG5vdCBwcm92aWRlZA0K DQogICAgICBQZW5kaW5nICAgRXJyb3IgcHJvY2Vzc2luZyBzdWNjZXNzZnVsICAgIFNlbnQgU1RS ICAgRGlzY29uDQogICAgICAgICAgICAgICAgU2VydmljZS1zcGVjaWZpYyBhdXRob3JpemF0aW9u DQogICAgICAgICAgICAgICAgYW5zd2VyDQoNCiAgICAgIFBlbmRpbmcgICBGYWlsZWQgU2Vydmlj ZS1zcGVjaWZpYyAgICAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAgYXV0aG9y aXphdGlvbiBhbnN3ZXIgcmVjZWl2ZWQNCg0KICAgICAgT3BlbiAgICAgIHVzZXIgb3IgY2xpZW50 IGRldmljZSAgICAgICAgICBTZW5kICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICByZXF1ZXN0 cyBhY2Nlc3MgdG8gc2VydmljZSAgICAgc2VydmljZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpYw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhdXRoIHJlcQ0KDQogICAgICBPcGVuICAgICAgU3VjY2Vz c2Z1bCBTZXJ2aWNlLXNwZWNpZmljICAgIEV4dGVuZCAgICAgT3Blbg0KICAgICAgICAgICAgICAg IGF1dGhvcml6YXRpb24gYW5zd2VyIHJlY2VpdmVkICBBbnN3ZXINCg0KICAgICAgT3BlbiAgICAg IEZhaWxlZCBTZXJ2aWNlLXNwZWNpZmljICAgICAgICBEaXNjb24uICAgIElkbGUNCiAgICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAgICAgdXNlci9kZXZpY2UNCiAgICAg ICAgICAgICAgICByZWNlaXZlZC4NCg0KICAgICAgT3BlbiAgICAgIFNlc3Npb24tVGltZW91dCBF eHBpcmVzIG9uICAgICBTZW5kIFNUUiAgIERpc2Nvbg0KICAgICAgICAgICAgICAgIEFjY2VzcyBE ZXZpY2UNCg0KICAgICAgT3BlbiAgICAgIEFTUiBSZWNlaXZlZCwgICAgICAgICAgICAgICAgICBT ZW5kIEFTQSAgIERpc2Nvbg0KICAgICAgICAgICAgICAgIGNsaWVudCB3aWxsIGNvbXBseSB3aXRo ICAgICAgICB3aXRoDQogICAgICAgICAgICAgICAgcmVxdWVzdCB0byBlbmQgdGhlIHNlc3Npb24g ICAgIFJlc3VsdC1Db2RlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID0gU1VDQ0VTUywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2VuZCBTVFIuDQoNCiAgICAgIE9wZW4gICAgICBBU1IgUmVjZWl2ZWQsICAgICAg ICAgICAgICAgICAgU2VuZCBBU0EgICBPcGVuDQogICAgICAgICAgICAgICAgY2xpZW50IHdpbGwg bm90IGNvbXBseSB3aXRoICAgIHdpdGgNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHRvIGVuZCB0 aGUgc2Vzc2lvbiAgICAgUmVzdWx0LUNvZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIT0gU1VDQ0VTUw0KDQogICAgICBPcGVuICAgICAgQXV0aG9yaXph dGlvbi1MaWZldGltZSArICAgICAgIFNlbmQgU1RSICAgRGlzY29uDQogICAgICAgICAgICAgICAg QXV0aC1HcmFjZS1QZXJpb2QgZXhwaXJlcyBvbg0KICAgICAgICAgICAgICAgIGFjY2VzcyBkZXZp Y2UNCg0KICAgICAgRGlzY29uICAgIEFTUiBSZWNlaXZlZCAgICAgICAgICAgICAgICAgICBTZW5k IEFTQSAgIERpc2Nvbg0KDQogICAgICBEaXNjb24gICAgU1RBIFJlY2VpdmVkICAgICAgICAgICAg ICAgICAgIERpc2Nvbi4gICAgSWRsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1c2VyL2RldmljZQ0KDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFj aGluZSBpcyBvYnNlcnZlZCBieSBhIHNlcnZlciB3aGVuIGl0IGlzDQogICBtYWludGFpbmluZyBz dGF0ZSBmb3IgdGhlIHNlc3Npb246DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0VS VkVSLCBTVEFURUZVTA0KICAgICAgU3RhdGUgICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAg ICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgSWRsZSAgICAgIFNl cnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBTZW5kICAgICAgIE9wZW4NCiAgICAgICAgICAg ICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQgICAgICAgICAgc3VjY2Vzc2Z1bA0KICAgICAgICAg ICAgICAgIHVzZXIgaXMgYXV0aG9yaXplZCAgICAgICAgICAgICBzZXJ2Lg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpYyBhbnN3ZXINCg0KICAg ICAgSWRsZSAgICAgIFNlcnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBTZW5kICAgICAgIElk bGUNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQgICAgICAgICAgZmFpbGVk IHNlcnYuDQogICAgICAgICAgICAgICAgdXNlciBpcyBub3QgYXV0aG9yaXplZCAgICAgICAgIHNw ZWNpZmljIGFuc3dlcg0KDQogICAgICBPcGVuICAgICAgU2VydmljZS1zcGVjaWZpYyBhdXRob3Jp emF0aW9uIFNlbmQgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIHJlcXVlc3QgcmVjZWl2ZWQs IGFuZCB1c2VyICAgICBzdWNjZXNzZnVsDQogICAgICAgICAgICAgICAgaXMgYXV0aG9yaXplZCAg ICAgICAgICAgICAgICAgIHNlcnYuIHNwZWNpZmljDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBPcGVuICAgICAgU2VydmljZS1z cGVjaWZpYyBhdXRob3JpemF0aW9uIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJl cXVlc3QgcmVjZWl2ZWQsIGFuZCB1c2VyICAgICBmYWlsZWQgc2Vydi4NCiAgICAgICAgICAgICAg ICBpcyBub3QgYXV0aG9yaXplZCAgICAgICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5zd2VyLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDbGVhbnVwDQoNCiAgICAgIE9wZW4gICAg ICBIb21lIHNlcnZlciB3YW50cyB0byAgICAgICAgICAgU2VuZCBBU1IgICBPcGVuDQogICAgICAg ICAgICAgICAgdGVybWluYXRlIHRoZSBzZXJ2aWNlDQoNCiAgICAgIE9wZW4gICAgICBBU0EgUmVj ZWl2ZWQgICAgICAgICAgICAgICAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAg d2l0aCBSZXN1bHQtQ29kZQ0KICAgICAgICAgICAgICAgID0gVU5LTk9XTi1TRVNTSU9OLUlEDQoN CiAgICAgIE9wZW4gICAgICBBU0EgUmVjZWl2ZWQgICAgICAgICAgICAgICAgICAgTm9uZSAgICAg ICBPcGVuDQogICAgICAgICAgICAgICAgd2l0aCBSZXN1bHQtQ29kZSAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgIG5vdCA9IFVOS05PV04tU0VTU0lPTi1JRA0KDQogICAgICBPcGVuICAg ICAgQXV0aG9yaXphdGlvbi1MaWZldGltZSAoYW5kICAgIENsZWFudXAgICAgSWRsZQ0KICAgICAg ICAgICAgICAgIEF1dGgtR3JhY2UtUGVyaW9kKSBleHBpcmVzDQogICAgICAgICAgICAgICAgb24g aG9tZSBzZXJ2ZXIuDQoNCiAgICAgIE9wZW4gICAgICBTZXNzaW9uLVRpbWVvdXQgZXhwaXJlcyBv biAgICAgQ2xlYW51cCAgICBJZGxlDQogICAgICAgICAgICAgICAgaG9tZSBzZXJ2ZXINCg0KICAg ICAgT3BlbiAgICAgIFNUUiBSZWNlaXZlZCAgICAgICAgICAgICAgICAgICBTZW5kIFNUQSwgIElk bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xlYW51 cA0KDQogICAgICBOb3QgICAgICAgQVNBIFJlY2VpdmVkICAgICAgICAgICAgICAgICAgIE5vbmUg ICAgICAgTm8gQ2hhbmdlLg0KICAgICAgT3Blbg0KDQogICAgICBOb3QgICAgICAgU1RSIFJlY2Vp dmVkICAgICAgICAgICAgICAgICAgIFNlbmQgU1RBLCAgSWRsZQ0KICAgICAgT3BlbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDbGVhbnVwDQoNCg0KDQogICBUaGUgZm9sbG93 aW5nIHN0YXRlIG1hY2hpbmUgaXMgb2JzZXJ2ZWQgYnkgYSBjbGllbnQgd2hlbiBzdGF0ZSBpcw0K ICAgbm90IG1haW50YWluZWQgb24gdGhlIHNlcnZlcjoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ0xJRU5ULCBTVEFURUxFU1MNCiAgICAgIFN0YXRlICAgICBFdmVudCAgICAgICAg ICAgICAgICAgICAgICAgICAgQWN0aW9uICAgICBOZXcgU3RhdGUNCiAgICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg IElkbGUgICAgICBDbGllbnQgb3IgRGV2aWNlIFJlcXVlc3RzICAgICAgU2VuZCAgICAgICBQZW5k aW5nDQogICAgICAgICAgICAgICAgYWNjZXNzICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZp Y2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lm aWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXV0aCBy ZXENCg0KICAgICAgUGVuZGluZyAgIFN1Y2Nlc3NmdWwgU2VydmljZS1zcGVjaWZpYyAgICBHcmFu dCAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGFuc3dlciAgICAgICAg ICAgQWNjZXNzDQogICAgICAgICAgICAgICAgcmVjZWl2ZWQgd2l0aCBBdXRoLVNlc3Npb24tDQog ICAgICAgICAgICAgICAgU3RhdGUgc2V0IHRvDQogICAgICAgICAgICAgICAgTk9fU1RBVEVfTUFJ TlRBSU5FRA0KDQogICAgICBQZW5kaW5nICAgRmFpbGVkIFNlcnZpY2Utc3BlY2lmaWMgICAgICAg IENsZWFudXAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gYW5zd2VyDQog ICAgICAgICAgICAgICAgcmVjZWl2ZWQNCg0KICAgICAgT3BlbiAgICAgIFNlc3Npb24tVGltZW91 dCBFeHBpcmVzIG9uICAgICBEaXNjb24uICAgIElkbGUNCiAgICAgICAgICAgICAgICBBY2Nlc3Mg RGV2aWNlICAgICAgICAgICAgICAgICAgdXNlci9kZXZpY2UNCg0KICAgICAgT3BlbiAgICAgIFNl cnZpY2UgdG8gdXNlciBpcyB0ZXJtaW5hdGVkICBEaXNjb24uICAgIElkbGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlci9kZXZpY2UNCg0KDQoNCiAg IFRoZSBmb2xsb3dpbmcgc3RhdGUgbWFjaGluZSBpcyBvYnNlcnZlZCBieSBhIHNlcnZlciB3aGVu IGl0IGlzIG5vdA0KICAgbWFpbnRhaW5pbmcgc3RhdGUgZm9yIHRoZSBzZXNzaW9uOg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIsIFNUQVRFTEVTUw0KICAgICAgU3RhdGUg ICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0K ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KICAgICAgSWRsZSAgICAgIFNlcnZpY2Utc3BlY2lmaWMgYXV0aG9yaXphdGlv biBTZW5kIHNlcnYuIElkbGUNCiAgICAgICAgICAgICAgICByZXF1ZXN0IHJlY2VpdmVkLCBhbmQg ICAgICAgICAgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICBzdWNjZXNzZnVsbHkgcHJvY2Vzc2Vk ICAgICAgICAgYW5zd2VyDQoNCg0KOC4yICBBY2NvdW50aW5nIFNlc3Npb24gU3RhdGUgTWFjaGlu ZQ0KDQogICBGb3IgYXBwbGljYXRpb25zIHRoYXQgb25seSByZXF1aXJlIGFjY291bnRpbmcgc2Vy dmljZXMgb3INCiAgIGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgYW4gYWNjb3VudGluZyBwb3J0aW9u LCB0aGUgZm9sbG93aW5nIHN0YXRlDQogICBtYWNoaW5lcyBNVVNUIGJlIHN1cHBvcnRlZC4gVGhl IGZpcnN0IGlzIHRvIGJlIG9ic2VydmVkIGJ5IGNsaWVudHMsDQogICB0aGUgc2Vjb25kIGJ5IHNl cnZlcnMuDQoNCiAgIFdoZW4gYSBzZXNzaW9uIGlzIG1vdmVkIHRvIHRoZSBJZGxlIHN0YXRlLCBh bnkgcmVzb3VyY2VzIHRoYXQgd2VyZQ0KICAgYWxsb2NhdGVkIGZvciB0aGUgcGFydGljdWxhciBz ZXNzaW9uIG11c3QgYmUgcmVsZWFzZWQuICBBbnkgZXZlbnQgbm90DQogICBsaXN0ZWQgaW4gdGhl IHN0YXRlIG1hY2hpbmVzIE1VU1QgYmUgY29uc2lkZXJlZCBhcyBhbiBlcnJvcg0KICAgY29uZGl0 aW9uLCBhbmQgYW4gYW5zd2VyLCBpZiBhcHBsaWNhYmxlLCBNVVNUIGJlIHJldHVybmVkIHRvIHRo ZQ0KICAgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4NCg0KICAgSW4gdGhlIHN0YXRlIHRhYmxl LCB0aGUgZXZlbnQgJ0ZhaWx1cmUgdG8gc2VuZCcgbWVhbnMgdGhhdCB0aGUNCiAgIERpYW1ldGVy IGNsaWVudCBpcyB1bmFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgZGVzaXJlZA0KICAgZGVz dGluYXRpb24uIFRoaXMgY291bGQgYmUgZHVlIHRvIHRoZSBwZWVyIGJlaW5nIGRvd24sIG9yIGR1 ZSB0bw0KICAgdGhlIHBlZXIgc2VuZGluZyBiYWNrIGEgdHJhbnNpZW50IGZhaWx1cmUgb3IgdGVt cG9yYXJ5IHByb3RvY29sDQogICBlcnJvciBub3RpZmljYXRpb24gRElBTUVURVJfT1VUX09GX1NQ QUNFLCBESUFNRVRFUl9UT09fQlVTWSwgb3INCiAgIERJQU1FVEVSX0xPT1BfREVURUNURUQgaW4g dGhlIFJlc3VsdC1Db2RlIEFWUCBvZiB0aGUgQWNjb3VudGluZw0KICAgQW5zd2VyIGNvbW1hbmQu DQoNCiAgIFRoZSBldmVudCAnRmFpbGVkIGFuc3dlcicgbWVhbnMgdGhhdCB0aGUgRGlhbWV0ZXIg Y2xpZW50IHJlY2VpdmVkIGENCiAgIG5vbi10cmFuc2llbnQgZmFpbHVyZSBub3RpZmljYXRpb24g aW4gdGhlIEFjY291bnRpbmcgQW5zd2VyDQogICBjb21tYW5kLg0KDQogICBOb3RlIHRoYXQgdGhl IGFjdGlvbiAnRGlzY29ubmVjdCB1c2VyL2RldicgTVVTVCBoYXZlIGFuIGVmZmVjdCBhbHNvDQog ICB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXNzaW9uIHN0YXRlIHRhYmxlLCBlLmcuIGNhdXNlIHRo ZSBTVFINCiAgIG1lc3NhZ2UgdG8gYmUgc2VudCwgaWYgdGhlIGdpdmVuIGFwcGxpY2F0aW9uIGhh cyBib3RoDQogICBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIHBv cnRpb25zLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDTElFTlQsIEFDQ09VTlRJ TkcNCiAgICAgIFN0YXRlICAgICBFdmVudCAgICAgICAgICAgICAgICAgICAgICAgICAgQWN0aW9u ICAgICBOZXcgU3RhdGUNCiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIElkbGUgICAgICBDbGllbnQgb3IgZGV2 aWNlIHJlcXVlc3RzICAgICAgU2VuZCAgICAgICBQZW5kaW5nUw0KICAgICAgICAgICAgICAgIGFj Y2VzcyAgICAgICAgICAgICAgICAgICAgICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXJ0IHJlcS4NCg0KICAgICAgSWRsZSAg ICAgIENsaWVudCBvciBkZXZpY2UgcmVxdWVzdHMgICAgICBTZW5kICAgICAgIFBlbmRpbmdFDQog ICAgICAgICAgICAgICAgYSBvbmUtdGltZSBzZXJ2aWNlICAgICAgICAgICAgIGFjY291bnRpbmcN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXZlbnQgcmVx DQoNCiAgICAgIElkbGUgICAgICBSZWNvcmRzIGluIHN0b3JhZ2UgICAgICAgICAgICAgU2VuZCAg ICAgICBQZW5kaW5nQg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZWNvcmQNCg0KICAgICAgUGVuZGluZ1MgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyAgICAg ICAgICAgICAgICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzdGFydCBhbnN3ZXIgcmVjZWl2 ZWQNCg0KICAgICAgUGVuZGluZ1MgIEZhaWx1cmUgdG8gc2VuZCBhbmQgYnVmZmVyICAgICBTdG9y ZSAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgYW5kIHJlYWx0aW1l ICAgU3RhcnQNCiAgICAgICAgICAgICAgICBub3QgZXF1YWwgdG8gREVMSVZFUl9BTkRfR1JBTlQg UmVjb3JkDQoNCiAgICAgIFBlbmRpbmdTICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAg ICAgICAgICAgICBPcGVuDQogICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlIGFuZCByZWFs dGltZQ0KICAgICAgICAgICAgICAgIGVxdWFsIHRvIEdSQU5UX0FORF9MT1NFDQoNCiAgICAgIFBl bmRpbmdTICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAgRGlzY29ubmVjdCBJZGxlDQog ICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlIGFuZCByZWFsdGltZSAgIHVzZXIvZGV2DQog ICAgICAgICAgICAgICAgbm90IGVxdWFsIHRvDQogICAgICAgICAgICAgICAgR1JBTlRfQU5EX0xP U0UNCg0KICAgICAgUGVuZGluZ1MgIEZhaWxlZCBhY2NvdW50aW5nIHN0YXJ0IGFuc3dlciAgICAg ICAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICByZWNlaXZlZCBhbmQgcmVhbHRpbWUgZXF1YWwN CiAgICAgICAgICAgICAgICB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQZW5kaW5nUyAgRmFp bGVkIGFjY291bnRpbmcgc3RhcnQgYW5zd2VyIERpc2Nvbm5lY3QgSWRsZQ0KICAgICAgICAgICAg ICAgIHJlY2VpdmVkIGFuZCByZWFsdGltZSBub3QgICAgICB1c2VyL2Rldg0KICAgICAgICAgICAg ICAgIGVxdWFsIHRvIEdSQU5UX0FORF9MT1NFDQoNCiAgICAgIFBlbmRpbmdTICBVc2VyIHNlcnZp Y2UgdGVybWluYXRlZCAgICAgICAgU3RvcmUgICAgICBQZW5kaW5nUw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdG9wDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBPcGVuICAgICAgSW50 ZXJpbSBpbnRlcnZhbCBlbGFwc2VzICAgICAgIFNlbmQgICAgICAgUGVuZGluZ0kNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3VudGluZw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcmltDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBP cGVuICAgICAgVXNlciBzZXJ2aWNlIHRlcm1pbmF0ZWQgICAgICAgIFNlbmQgICAgICAgUGVuZGlu Z0wNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3Vu dGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdG9w IHJlcS4NCg0KICAgICAgUGVuZGluZ0kgIEZhaWx1cmUgdG8gc2VuZCBhbmQgKGJ1ZmZlciAgICBT dG9yZSAgICAgIE9wZW4NCiAgICAgICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgb3Igb2xkIHJl Y29yZCAgaW50ZXJpbQ0KICAgICAgICAgICAgICAgIGNhbiBiZSBvdmVyd3JpdHRlbikgYW5kICAg ICAgICByZWNvcmQNCiAgICAgICAgICAgICAgICByZWFsdGltZSBub3QgZXF1YWwgdG8NCiAgICAg ICAgICAgICAgICBERUxJVkVSX0FORF9HUkFOVA0KDQogICAgICBQZW5kaW5nSSAgRmFpbHVyZSB0 byBzZW5kIGFuZCBubyBidWZmZXIgICAgICAgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIHNw YWNlIGF2YWlsYWJsZSBhbmQgcmVhbHRpbWUNCiAgICAgICAgICAgICAgICBlcXVhbCB0byBHUkFO VF9BTkRfTE9TRQ0KDQogICAgICBQZW5kaW5nSSAgRmFpbHVyZSB0byBzZW5kIGFuZCBubyBidWZm ZXIgIERpc2Nvbm5lY3QgSWRsZQ0KICAgICAgICAgICAgICAgIHNwYWNlIGF2YWlsYWJsZSBhbmQg cmVhbHRpbWUgICB1c2VyL2Rldg0KICAgICAgICAgICAgICAgIG5vdCBlcXVhbCB0byBHUkFOVF9B TkRfTE9TRQ0KDQogICAgICBQZW5kaW5nSSAgRmFpbGVkIGFjY291bnRpbmcgaW50ZXJpbSAgICAg ICAgICAgICAgICAgT3Blbg0KICAgICAgICAgICAgICAgIGFuc3dlciByZWNlaXZlZCBhbmQgcmVh bHRpbWUNCiAgICAgICAgICAgICAgICBlcXVhbCB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQ ZW5kaW5nSSAgRmFpbGVkIGFjY291bnRpbmcgaW50ZXJpbSAgICAgIERpc2Nvbm5lY3QgSWRsZQ0K ICAgICAgICAgICAgICAgIGFuc3dlciByZWNlaXZlZCBhbmQgcmVhbHRpbWUgICB1c2VyL2Rldg0K ICAgICAgICAgICAgICAgIG5vdCBlcXVhbCB0byBHUkFOVF9BTkRfTE9TRQ0KDQogICAgICBQZW5k aW5nSSAgVXNlciBzZXJ2aWNlIHRlcm1pbmF0ZWQgICAgICAgIFN0b3JlICAgICAgUGVuZGluZ0kN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RvcA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWNvcmQNCg0KICAg ICAgUGVuZGluZ0UgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyAgICAgICAgICAgICAgICAgICAgIElk bGUNCiAgICAgICAgICAgICAgICBldmVudCBhbnN3ZXIgcmVjZWl2ZWQNCg0KICAgICAgUGVuZGlu Z0UgIEZhaWx1cmUgdG8gc2VuZCBhbmQgYnVmZmVyICAgICBTdG9yZSAgICAgIElkbGUNCiAgICAg ICAgICAgICAgICBzcGFjZSBhdmFpbGFibGUgICAgICAgICAgICAgICAgZXZlbnQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBl bmRpbmdFICBGYWlsdXJlIHRvIHNlbmQgYW5kIG5vIGJ1ZmZlciAgICAgICAgICAgICBJZGxlDQog ICAgICAgICAgICAgICAgc3BhY2UgYXZhaWxhYmxlDQoNCiAgICAgIFBlbmRpbmdFICBGYWlsZWQg YWNjb3VudGluZyBldmVudCBhbnN3ZXIgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAg cmVjZWl2ZWQNCg0KICAgICAgUGVuZGluZ0IgIFN1Y2Nlc3NmdWwgYWNjb3VudGluZyBhbnN3ZXIg ICBEZWxldGUgICAgIElkbGUNCiAgICAgICAgICAgICAgICByZWNlaXZlZCAgICAgICAgICAgICAg ICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBlbmRpbmdCICBGYWlsdXJlIHRvIHNlbmQgICAgICAg ICAgICAgICAgICAgICAgICAgICBJZGxlDQoNCiAgICAgIFBlbmRpbmdCICBGYWlsZWQgYWNjb3Vu dGluZyBhbnN3ZXIgICAgICAgRGVsZXRlICAgICBJZGxlDQogICAgICAgICAgICAgICAgcmVjZWl2 ZWQgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZA0KDQogICAgICBQZW5kaW5nTCAgU3VjY2Vz c2Z1bCBhY2NvdW50aW5nICAgICAgICAgICAgICAgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAg IHN0b3AgYW5zd2VyIHJlY2VpdmVkDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsdXJlIHRvIHNlbmQg YW5kIGJ1ZmZlciAgICAgU3RvcmUgICAgICBJZGxlDQogICAgICAgICAgICAgICAgc3BhY2UgYXZh aWxhYmxlICAgICAgICAgICAgICAgIHN0b3ANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmVjb3JkDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsdXJlIHRvIHNl bmQgYW5kIG5vIGJ1ZmZlciAgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAgc3BhY2Ug YXZhaWxhYmxlDQoNCiAgICAgIFBlbmRpbmdMICBGYWlsZWQgYWNjb3VudGluZyBzdG9wIGFuc3dl ciAgICAgICAgICAgICBJZGxlDQogICAgICAgICAgICAgICAgcmVjZWl2ZWQNCg0KDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNFUlZFUiwgQUNDT1VOVElORw0KICAgICAgU3RhdGUg ICAgIEV2ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICBBY3Rpb24gICAgIE5ldyBTdGF0ZQ0K ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogICAgICBJZGxlICAgICAgQWNjb3VudGluZyBzdGFydCByZXF1ZXN0ICAg ICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJlY2VpdmVkLCBhbmQgc3VjY2Vz c2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgcHJvY2Vzc2VkLiAgICAgICAg ICAgICAgICAgICAgIHN0YXJ0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgQWNjb3VudGluZyBldmVudCByZXF1 ZXN0ICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIHJlY2VpdmVkLCBhbmQg c3VjY2Vzc2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgcHJvY2Vzc2VkLiAg ICAgICAgICAgICAgICAgICAgIGV2ZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgSW50ZXJpbSByZWNvcmQg cmVjZWl2ZWQsICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAgIGFuZCBzdWNj ZXNzZnVsbHkgcHJvY2Vzc2VkLiAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFuc3dlcg0KDQogICAgICBJZGxlICAgICAgQWNjb3Vu dGluZyBzdG9wIHJlcXVlc3QgICAgICAgIFNlbmQgICAgICAgSWRsZQ0KICAgICAgICAgICAgICAg IHJlY2VpdmVkLCBhbmQgc3VjY2Vzc2Z1bGx5ICAgICBhY2NvdW50aW5nDQogICAgICAgICAgICAg ICAgcHJvY2Vzc2VkICAgICAgICAgICAgICAgICAgICAgIHN0b3AgYW5zd2VyDQoNCiAgICAgIElk bGUgICAgICBBY2NvdW50aW5nIHJlcXVlc3QgcmVjZWl2ZWQsICAgU2VuZCAgICAgICBJZGxlDQog ICAgICAgICAgICAgICAgbm8gc3BhY2UgbGVmdCB0byBzdG9yZSAgICAgICAgIGFjY291bnRpbmcN CiAgICAgICAgICAgICAgICByZWNvcmRzICAgICAgICAgICAgICAgICAgICAgICAgYW5zd2VyLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN1bHQtQ29k ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IE9VVF9P Rl8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU1BBQ0UN Cg== ------_=_NextPart_002_01C1D988.14C02180-- ------_=_NextPart_001_01C1DB0D.42EDBAE8-- From owner-aaa-wg@merit.edu Wed Apr 3 07:57:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01513 for ; Wed, 3 Apr 2002 07:57:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22E4A91222; Wed, 3 Apr 2002 07:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E726E91228; Wed, 3 Apr 2002 07:57:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F107791222 for ; Wed, 3 Apr 2002 07:57:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id D43C65DDAD; Wed, 3 Apr 2002 07:57:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 27DC75DD90 for ; Wed, 3 Apr 2002 07:57:27 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g33CvP3G023363; Wed, 3 Apr 2002 14:57:26 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g33CvPUD012511; Wed, 3 Apr 2002 15:57:25 +0300 (EET DST) Message-ID: <3CAAFC35.42A17F3E@lmf.ericsson.se> Date: Wed, 03 Apr 2002 15:57:25 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Elena.Lialiamou@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B7B75C6@esebe015.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Elena for your comments. Some responses below: > All the states proposed for Server Accounting are Idle (check the diamstates.txt).How is that possible? > Shouldn't at least Open and Idle be required/ needed for the server side ? Well, the original splitted table sent by Pete did have Open and Idle. However, I wasn't sure if this added any useful value to the state machine. Are we supposed to reject an Interim record if we didn't receive a Start earlier? In some ways that would make sense, but on the other hand, I would think we would like to get even some records if for some reason the earlier records have been lost, e.g. due to network partiotion and lack of memory. Secondly, what if there is some reordering between accounting records under some strange network condition and the Start arrives later than the interim? We aren't supposed to be doing that on the client side, but again I wonder if we should really drop the records on the floor if we do receive them in the wrong order. So, unless we are going to do something different in the Open/Idle states, we aren't going to need states. > Also, in previous email with regard to the same topic > some additional state-event transitions in particular > Interim Record was presented which is not included in the diamstates.txt . I'm not sure what you are missing, can you clarify? The state machine does have Open-> PendingI and then 5 different actions on what to do there. Jari From owner-aaa-wg@merit.edu Wed Apr 3 08:05:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01795 for ; Wed, 3 Apr 2002 08:05:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 94AE391228; Wed, 3 Apr 2002 08:05:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5671791282; Wed, 3 Apr 2002 08:05:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31BEF91228 for ; Wed, 3 Apr 2002 08:05:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BEC65DDC3; Wed, 3 Apr 2002 08:05:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 296785DDB8 for ; Wed, 3 Apr 2002 08:05:29 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g33C5Yx29647; Wed, 3 Apr 2002 14:05:36 +0200 Message-ID: <3CAAFDE4.7050405@ipunplugged.com> Date: Wed, 03 Apr 2002 15:04:36 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Jari Arkko Cc: Elena.Lialiamou@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B7B75C6@esebe015.NOE.Nokia.com> <3CAAFC35.42A17F3E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko wrote: > >I'm not sure what you are missing, can you clarify? >The state machine does have Open-> PendingI and then >5 different actions on what to do there. > What do the I, B, E, S and L letters denote anyway? I could try to guess but I'd rather not. j From owner-aaa-wg@merit.edu Wed Apr 3 08:12:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02168 for ; Wed, 3 Apr 2002 08:12:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B48D91282; Wed, 3 Apr 2002 08:12:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4E7B91283; Wed, 3 Apr 2002 08:12:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D352E91282 for ; Wed, 3 Apr 2002 08:12:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id B928D5DDCB; Wed, 3 Apr 2002 08:12:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id 39F8D5DDB8 for ; Wed, 3 Apr 2002 08:12:03 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g33DC2s7027227; Wed, 3 Apr 2002 15:12:02 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g33DC0UD013379; Wed, 3 Apr 2002 16:12:00 +0300 (EET DST) Message-ID: <3CAAFFA0.DA9DACAC@lmf.ericsson.se> Date: Wed, 03 Apr 2002 16:12:00 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: Elena.Lialiamou@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B7B75C6@esebe015.NOE.Nokia.com> <3CAAFC35.42A17F3E@lmf.ericsson.se> <3CAAFDE4.7050405@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > > Jari Arkko wrote: > > > > >I'm not sure what you are missing, can you clarify? > >The state machine does have Open-> PendingI and then > >5 different actions on what to do there. > > > What do the I, B, E, S and L letters denote anyway? I could try to > guess but I'd rather not. PendingI=Interim/B=Buffer/E=Event/S=Start/L=Stop Jari From owner-aaa-wg@merit.edu Wed Apr 3 08:21:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02390 for ; Wed, 3 Apr 2002 08:21:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F78591283; Wed, 3 Apr 2002 08:21:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 012F491284; Wed, 3 Apr 2002 08:21:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2F8691283 for ; Wed, 3 Apr 2002 08:21:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id A99AA5DDB8; Wed, 3 Apr 2002 08:21:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id DC0145DDB6 for ; Wed, 3 Apr 2002 08:21:25 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g33DLd503730 for ; Wed, 3 Apr 2002 16:21:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 16:21:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 16:21:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Wed, 3 Apr 2002 16:21:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D9E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbEmNWXHwQkFhFTWWeMsVUcRVMZQAAAZ0w From: To: , Cc: , X-OriginalArrivalTime: 03 Apr 2002 13:21:24.0360 (UTC) FILETIME=[73E89080:01C1DB12] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA02390 Hi, > > >I'm not sure what you are missing, can you clarify? > > >The state machine does have Open-> PendingI and then > > >5 different actions on what to do there. > > > > > What do the I, B, E, S and L letters denote anyway? I could try to > > guess but I'd rather not. > > PendingI=Interim/B=Buffer/E=Event/S=Start/L=Stop I guess those should be added to the text ... John From owner-aaa-wg@merit.edu Wed Apr 3 08:22:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02423 for ; Wed, 3 Apr 2002 08:22:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C014691284; Wed, 3 Apr 2002 08:22:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93CCE91285; Wed, 3 Apr 2002 08:22:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A237791284 for ; Wed, 3 Apr 2002 08:21:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 831F55DDB8; Wed, 3 Apr 2002 08:21:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id D58C35DDB6 for ; Wed, 3 Apr 2002 08:21:58 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g33DLvs7002971; Wed, 3 Apr 2002 15:21:57 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g33DLuUD013983; Wed, 3 Apr 2002 16:21:56 +0300 (EET DST) Message-ID: <3CAB01F4.6983193C@lmf.ericsson.se> Date: Wed, 03 Apr 2002 16:21:56 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Elena.Lialiamou@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B7B75C6@esebe015.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Elena.Lialiamou@nokia.com wrote: > Also, in previous email with regard to the same topic some additional state-event transitions in particular Interim Record was presented which is not included in the diamstates.txt . Ah, perhaps you mean the missing state transition from PendingI back to Open, for a succesful answer... yeah that needs to be added. I've been dealing with these complicated error cases for so long that I tend to forget the normal case! Jari From owner-aaa-wg@merit.edu Wed Apr 3 08:47:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03072 for ; Wed, 3 Apr 2002 08:47:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7E6C91285; Wed, 3 Apr 2002 08:47:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D67D91286; Wed, 3 Apr 2002 08:47:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F41E991285 for ; Wed, 3 Apr 2002 08:47:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4BD65DDCD; Wed, 3 Apr 2002 08:47:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 0BB1D5DDC3 for ; Wed, 3 Apr 2002 08:47:38 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g33Dlq518811 for ; Wed, 3 Apr 2002 16:47:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 16:47:31 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 16:47:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Wed, 3 Apr 2002 16:47:31 +0300 Message-ID: <93532512B06FC3489824C18037DB3D4B091C2A@esebe015.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbD/+NYUQv6WTiS1KIXhZGFUX6UAAA9P+g From: To: Cc: , X-OriginalArrivalTime: 03 Apr 2002 13:47:31.0572 (UTC) FILETIME=[1A0A2340:01C1DB16] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03072 Hi, With regard to the need of having accounting states or not: 1. According to the definition of the Idle state means " When a session is moved to the Idle state, any resources that were allocated for the particular session must be released" 2.It should be so that messages arrive in certain order ; otherwise should be rejected or at least processed differently.I think that an Interim should be rejected if a Start was not received before.Otherwise what is the purpose of the Start anyway if not matter in which order they arrive the result is exactly the same? So, we would not need start, interim or stop not even any order in which those should arrive. So, since there is start , interim and stop and those are linked to one accounting session there should be session states which are based on receiving those requests and sending corresponding responses. Otherwise, I cannot really understand the purpose of those different messages if in the end of the day there is only one state and always the same end result. Regards Elena > -----Original Message----- > From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > Sent: 03. April 2002 15:57 > To: Lialiamou Elena (NET-IMN/Helsinki) > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > Thanks Elena for your comments. Some responses below: > > > All the states proposed for Server Accounting are Idle > (check the diamstates.txt).How is that possible? > > Shouldn't at least Open and Idle be required/ needed for > the server side ? > > Well, the original splitted table sent by Pete did > have Open and Idle. However, I wasn't sure if this > added any useful value to the state machine. Are we > supposed to reject an Interim record if we didn't > receive a Start earlier? In some ways that would make > sense, but on the other hand, I would think we would > like to get even some records if for some reason the > earlier records have been lost, e.g. due to network > partiotion and lack of memory. Secondly, what if > there is some reordering between accounting records > under some strange network condition and the Start > arrives later than the interim? We aren't supposed to > be doing that on the client side, but again I wonder > if we should really drop the records on the floor > if we do receive them in the wrong order. > > So, unless we are going to do something different > in the Open/Idle states, we aren't going to need > states. > > > Also, in previous email with regard to the same topic > > some additional state-event transitions in particular > > Interim Record was presented which is not included in the > diamstates.txt . > > I'm not sure what you are missing, can you clarify? > The state machine does have Open-> PendingI and then > 5 different actions on what to do there. > > Jari > From owner-aaa-wg@merit.edu Wed Apr 3 10:16:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05583 for ; Wed, 3 Apr 2002 10:16:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0240991255; Wed, 3 Apr 2002 10:15:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C42B591288; Wed, 3 Apr 2002 10:15:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1EE391255 for ; Wed, 3 Apr 2002 10:15:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 984625DDAA; Wed, 3 Apr 2002 10:15:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 5D2285DDA2 for ; Wed, 3 Apr 2002 10:15:36 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 111256A905; Wed, 3 Apr 2002 18:15:30 +0300 (EEST) Message-ID: <3CAB0EE6.9010909@kolumbus.fi> Date: Wed, 03 Apr 2002 17:17:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Elena.Lialiamou@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B091C2A@esebe015.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Elena.Lialiamou@nokia.com wrote: > Hi, > > With regard to the need of having accounting states or not: > > 1. According to the definition of the Idle state means " When a session is moved to the Idle state, any resources that were allocated for the particular session must be released" This may not be the right text in the accounting side. I'll take care of rewording this. > 2.It should be so that messages arrive in certain order ; otherwise should be rejected or at least processed differently.I think that an Interim should be rejected if a Start was not received before.Otherwise what is the purpose of the Start anyway if not matter in which order they arrive the result is exactly the same? So, we would not need start, interim or stop not even any order in which those should arrive. > > So, since there is start , interim and stop and those are linked to one accounting session there should be session states which are based on receiving those requests and sending corresponding responses. > > Otherwise, I cannot really understand the purpose of those different messages if in the end of the day there is only one state and always the same end result. I believe there's a few different issues at play here: - Billing vs. just collecting data. At which stage do we make all the sanity checks and so on? Is it the task of the data collector (diameter accounting) or the billing process (some rather company specific mechanism and policies)? - State of the accounting server vs. real-world effects. Pretty much the same thing as above. The state of the diameter accounting server might not change due to a message being received, but there might still be a real-world event, such as my bank account balance getting (even) smaller because I used a service and the billing process used an accounting record from the diameter accounting server to bill me for it. - State vs. records. Accounting service must at least keep records in some sort of storage. Sometimes we may want to keep state as well, even do very complicated things like fraud detection. But do we need to keep state *always*? My opinion is that we should focus Diameter accounting on the data collection part, and allow but not require keeping state. But please comment if you feel differently. In any case I continue to be happy that Pete's split is revealing these discussion items! Jari From owner-aaa-wg@merit.edu Wed Apr 3 10:18:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05702 for ; Wed, 3 Apr 2002 10:18:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9BA8B9123F; Wed, 3 Apr 2002 10:18:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6577791288; Wed, 3 Apr 2002 10:18:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D58589123F for ; Wed, 3 Apr 2002 10:18:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B44C05DDC3; Wed, 3 Apr 2002 10:18:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id 13FDF5DDAA for ; Wed, 3 Apr 2002 10:18:07 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep04-svc.swip.net with ESMTP id <20020403151805.FHGJ16729.fep04-svc.swip.net@ipunplugged.com>; Wed, 3 Apr 2002 17:18:05 +0200 Message-ID: <3CAB1D74.5080103@ipunplugged.com> Date: Wed, 03 Apr 2002 17:19:16 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elena.Lialiamou@nokia.com Cc: Jari.Arkko@lmf.ericsson.se, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B091C2A@esebe015.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Elena.Lialiamou@nokia.com wrote: >1. According to the definition of the Idle state means " When a session is moved to the Idle state, any resources that were allocated for the particular session must be released" > Yes. But everything that is needed to recreate that state is contained in the ACR that the server receives. >2.It should be so that messages arrive in certain order ; otherwise should be rejected or at least processed differently. > But it is not possible to guarantee the order in which they arrive even if there is an order in which they are sent, especially not when sending stale records as the result of failure recovery. >I think that an Interim should be rejected if a Start was not received before.Otherwise what is the purpose of the Start anyway if not matter in which order they arrive the result is exactly the same? So, we would not need start, interim or stop not even any order in which those should arrive. > It matters when doing the billing. >Otherwise, I cannot really understand the purpose of those different messages if in the end of the day there is only one state and always the same end result. > The difference is the value of one avp that describes which "state" the accounting session is in. j > > >Regards >Elena > > >>-----Original Message----- >>From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] >>Sent: 03. April 2002 15:57 >>To: Lialiamou Elena (NET-IMN/Helsinki) >>Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State >>Machines into Client vs. Server >> >> >>Thanks Elena for your comments. Some responses below: >> >>>All the states proposed for Server Accounting are Idle >>> >>(check the diamstates.txt).How is that possible? >> >>>Shouldn't at least Open and Idle be required/ needed for >>> >>the server side ? >> >>Well, the original splitted table sent by Pete did >>have Open and Idle. However, I wasn't sure if this >>added any useful value to the state machine. Are we >>supposed to reject an Interim record if we didn't >>receive a Start earlier? In some ways that would make >>sense, but on the other hand, I would think we would >>like to get even some records if for some reason the >>earlier records have been lost, e.g. due to network >>partiotion and lack of memory. Secondly, what if >>there is some reordering between accounting records >>under some strange network condition and the Start >>arrives later than the interim? We aren't supposed to >>be doing that on the client side, but again I wonder >>if we should really drop the records on the floor >>if we do receive them in the wrong order. >> >>So, unless we are going to do something different >>in the Open/Idle states, we aren't going to need >>states. >> >>>Also, in previous email with regard to the same topic >>>some additional state-event transitions in particular >>>Interim Record was presented which is not included in the >>> >>diamstates.txt . >> >>I'm not sure what you are missing, can you clarify? >>The state machine does have Open-> PendingI and then >>5 different actions on what to do there. >> >>Jari >> > From owner-aaa-wg@merit.edu Wed Apr 3 11:45:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08715 for ; Wed, 3 Apr 2002 11:45:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 642D891292; Wed, 3 Apr 2002 11:44:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2423F9129F; Wed, 3 Apr 2002 11:44:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9822E91292 for ; Wed, 3 Apr 2002 11:44:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C8855DE09; Wed, 3 Apr 2002 11:44:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 425B55DE08 for ; Wed, 3 Apr 2002 11:44:34 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id C938B4004A2; Wed, 3 Apr 2002 08:44:27 -0800 (PST) Received: from hpindsra (sramam@hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id IAA07501; Wed, 3 Apr 2002 08:45:11 -0800 (PST) Date: Wed, 3 Apr 2002 08:45:10 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Johan Johansson Cc: Tony Johansson , AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host In-Reply-To: <3CAAD97C.9000906@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, 3 Apr 2002, Johan Johansson wrote: > Sivasundar Ramamurthy wrote: > > >> > >>The only text in the draft that touches this avp says that it is a copy > >>of the Origin-Host avp of the AMR. This means that you are keying your > >>SA on the diameter interface instead of the mobile ip tunneling > >>interface. I am not sure if it's a good idea to use something that is > >>invented by diameter to key the SA rather than something that the mobile > >>ip layer of the FA sends. > >> > > > >but does not the Origin-Host contain the FQDN of the FA? My > >assumption is that a DNS lookup on this FQDN might give us all the > >control addresses used by the FA. > > > Yes, it contains a DiameterIdentity that is defined to be an FQDN. First > of all I am not sure you could get all the ip addresses using DNS, but > assuming for the moment that you could, I guess it would work to try an > SA-lookup on all of them and use the first that matches. > > I suppose the FQDN might legally resolve to more than one ip address > even when used as a DiameterIdentity, but there is nothing that says > that this would include the interface(s) used for mobile ip traffic, > control or otherwise. true. > >>A couple of weeks ago I went through the latest mobile ip draft together > >>with Fredrik to see if this split between the tunneling interface and > >>the control interface is supported in "raw" mobile ip. It doesn't seem > >>to be explicitly disallowed at any rate, but I am still not convinced > >>that it can in fact be made to work. > >> > > > >Cant this happen when the "r" bit is set on the agent adv and the MN > >is using a co-located COA? Or if the advertised COA and the > >the control interface are different? > > > Revisiting this today we reached the conclusion that this is in fact a > serious error either in Diameter or MobileIP. The home agent can not > know which ip address to key the SA on. We agree that it is possible for > an FA to send the Diameter control traffic on one interface, the > MobileIP control traffic on a second interface and the MobilIP tunnel > traffic on a third interface. In raw mobile ip the preshared keys are > hopefully stored using the right ip address, but when the HA receives a > dynamically generated key it must know which ip address to store it under. > > Your example with the R bit is also a good one. You would probably be > guaranteed that the source address in the UDP packet differs from the > one used for the actual traffic, with the possible exclusion of when > using NATed addresses. In any case, the HA does not know which ip > address to use for it's SA with the FA. > > Note that this means that any implementation that assumes that it knows > how to key the SA is *severly broken*. > > I can see 3 different solutions to this problem. > > 1. Make the MIP-Foreign-Agent-Host avp a MIP-Foreign-Agent-Address > avp and make it mandatory in the AMR and HAR. This will work but might require the FA has to use the same control interface to forward all reg requests to this HA. This is needed if the HA has multiple SAs to the same FA and can expect the FA to use any of these SAs. > 2. Since the UDP header is part of the MobileIP protocol, include the > UDP header in the MIP-Reg-Request avp This may not work since the AAA authentication will fail for the MN, unless the header is added after the MN-AAA auth ext (if that makes sense at all!) > 3. Demand that the CoA is used to key SAs in MobileIP (fat chance - > but it is a possible solution) Another solution is retaining the FA-Host AVP and having the FA include its NAI in a FA-NAI extension in the UDP request. This ext MUST be used if a AAA distributed FA-HA key is used. This will let the HA key the SA on the FQDN of the FA instead of IP address. > >>Regarding detecting session continuation on the clients: I suppose the > >>issue arises only for stateless clients? And for stateless clients you > >>are moving the detection to the mobile ip layer, right? > >> > > > >but I was referring to the support for Handoff issues in Diameter MIP > >draft section 1.3. Using the FA-Host-AVP, the HA can determine if the > >MN has moved to a new realm or a different FA in the same realm. My > >understanding is that the HA maintains MN session per Realm, not per > >FA. But do remember that this particular usage of the AVP is a guess > >of mine.. :-) > > > No. It cannot know if fa1.fluffybunny.nowhere.net and > fa7.pinkelephant.nowhere.net are in the same realm or not. It only knows > that they are different FAs. It is also my understanding that the HA > maintains per MN sessions, not per FA or per realm. It would in other > words be an error for a handover between two different realms to be two > different sessions on the HA with different accounting multi session ids. aah! the realm cannot be determined from the FQDN. Anyway, this possible "usage" of the FA-Host AVP is out! Siva From owner-aaa-wg@merit.edu Wed Apr 3 12:17:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09566 for ; Wed, 3 Apr 2002 12:17:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1F3E91294; Wed, 3 Apr 2002 12:17:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87C2D91295; Wed, 3 Apr 2002 12:17:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9617B91294 for ; Wed, 3 Apr 2002 12:17:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A8035DDC5; Wed, 3 Apr 2002 12:17:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 66C2C5DDA2 for ; Wed, 3 Apr 2002 12:17:37 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 2E2E16C; Wed, 3 Apr 2002 12:17:37 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: [Fwd: Issue #299 and #301] Date: Wed, 3 Apr 2002 12:16:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3CAA75B7.9D3A2F2@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, I'm looking over your proposed solution to issues #299 and #301. Issue#301 has to do with how to distribute AAAH-generated session keys securely, and up to now this has relied on CMS. As does the resolved issue#266, on securely distributing an AAAF-generated FA-HA-Key, when there is a foreign HA. But I'm confused about CMS. That is, my understanding is that CMS is being held back, and that the Mobile IPv4 draft, and others, will move ahead without CMS. Here's some questions, so I can give you better feedback: Q1: Is it true that terms like "CMS" and "DSA" and "end-to-end security" shouldn't be part of the current Mobile IPv4 draft? Q2: If so, then is issue#301 being shelved for the time being? And the Mobile IPv4 draft will say something like "the only currently-available security for session keys is TLS". Q3: When CMS does come out, is the game plan to then update and release a new Mobile IPv4 RFC, with CMS security for session keys, and solutions for issues#266 and #301? Or is the plan that the CMS RFC will include information about how Mobile IPv4 can use CMS to hide session keys, so that the Mobile IPv4 RFC won't require updating? Thanks, Bob K. From owner-aaa-wg@merit.edu Wed Apr 3 13:49:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11942 for ; Wed, 3 Apr 2002 13:49:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 168A891299; Wed, 3 Apr 2002 13:49:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D43709129B; Wed, 3 Apr 2002 13:49:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D05E791299 for ; Wed, 3 Apr 2002 13:49:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7F895DE33; Wed, 3 Apr 2002 13:49:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 88AD65DDEA for ; Wed, 3 Apr 2002 13:49:15 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 97EF26C; Wed, 3 Apr 2002 13:49:14 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , "David Spence" , "Johan Johansson" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: [Fwd: Issue #299 and #301] Date: Wed, 3 Apr 2002 13:48:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CAA75B7.9D3A2F2@ericsson.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, I'm confused on a few points, so I hope you'll bear with me. Most of my comments are focused on issue#299: handling handoffs. I'll send separate comments more focused on issue#301: securing session keys. I've tagged my specific suggestions with "-->". Bob K. > -------- Original Message -------- > Subject: Issue #299 and #301 > Date: Mon, 01 Apr 2002 11:53:07 -0800 > From: Tony Johansson > To: aaa-wg@merit.edu > > All, > > I have worked on new proposed text for issue 299 and 301, see below, > based on the solution we agree upon at the IETF 53. Part of this > solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines > the needed AAAH NAI and the HA NAI, please see > http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt. > The draft have been submitted to the mobileip wg and will go to wg final > call if no major comments/issues are found on the mobileip wg list. > > I hope this solves the issue 299 and 301, however I need help to > understand how I should deal the newly submitted issue #321 regarding > CMS. Is it good enough to just move the CMS ref to informative? > > Comments please. > > /Tony > > > > Added to to section 1.0: > > "1.0 Introduction > > ... > > Furthermore, the nature of mobile IP also means that the mobile node > will do handoffs between different foreign agents and to guarantee > that a registered user always ends up in the same initial AAAH the > Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to > assist the AAAH in routing the messages to a mobile node's home agent > the mobile node MUST always include the HA NAI [AAANAI]. --> How about changing the tail of the first sentence to "the Mobile Node, upon changing his point of attachment for a given session, MUST include the home NAI and the AAAH NAI [AAANAI]". Just to make it clear that the AAAH NAI information isn't required in the initial Registration Request of a session. --> How about changing the second sentence to: "Finally, to assist the AAAH in routing the messages to a mobile node's home agent the mobile node MUST include the HA NAI [AAANAI], if including an HA IP address other than 0.0.0.0 or 255.255.255.255" --> The plan, then, is that exactly one AAAH will be employed for the life of a MN's session. And if that AAAH becomes unavailable, it is "game over" for the MN's session, even if other AAAHs are available? If this is true, should this be explicitly stated? > ... " > > I've made changes here and there in section 1.2, 1.3 and 1.4, so here is > the whole text... > > " 1.2 Inter-Realm Mobile IP > > When a Mobile Node node requests service by issuing a Registration > Request to the foreign agent, the foreign agent creates the AA- > Mobile-Node-Request (AMR) message, which includes the AVPs defined in > section 2.1. The Home Address, Home Agent, Mobile Node NAI and other > important fields are extracted from the registration messages for > possible inclusion as Diameter AVPs. The AMR message is then > forwarded to the local Diameter server, known as the AAA-Foreign, or > AAAF. > > Visited Realm Home Realm > +--------+ +--------+ > |abc.com | AMR/AMA |xyz.com | > | AAAF |<------------------->| AAAH | > +->| server | server-server | server | > | +--------+ communication +--------+ > | ^ ^ > | AMR/AMA | client-server | HAR/HAA > | | communication | > v v v > +---------+ +---------+ +---------+ > | Foreign | | Foreign | | Home | > | Agent | | Agent | | Agent | > +---------+ +---------+ +---------+ > ^ > | Mobile IP > | > v > +--------+ > | Mobile | > | Node | mn@xyz.com > +--------+ > Figure 1: Inter-Realm Mobility > > Upon receiving the AMR, the AAAF follows the procedures outlined in > [DIAMBASE] to determine whether the AMR should be processed locally, > or if it should be forwarded to another Diameter server, known as the > AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node > (mn@xyz.com) requests service from a foreign provider (abc.com). The > request received by the AAAF is forwarded to xyz.com's AAAH server. > > Figure 2 shows the message flows involved when the foreign agent > invokes the AAA infrastructure to request that a mobile node be > authenticated and authorized. Note that it is not required that the > foreign agent invoke AAA services every time a Registration Request > is received from the mobile, but rather only when the prior > authorization from the AAAH expires. The last sentence, beginning "Note that...", either needs more clarification, or maybe should be striken. For example, how (what is the algorithm by which) does the FA determine whether or not to invoke AAA services? Also, for example, doesn't this sentence conflict with the last sentence of the first paragraph of section 1.3, which says that "Therefore, it MUST be assumed that a foreign agent is not aware that a registration request from a mobile node has been previously authorized." Also, wouldn't there be other reasons for the FA to invoke AAA services, beyond "*only* when the prior authorization from the AAAH expires". E.g, the authorization might not have expired, but maybe the new FA needs an FA-xx key. Or the key lifetime is approaching expiration. --> I would suggest either striking the "Note that..." sentence altogether, or trimming it to "It is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile". > The expiration time of the > authorization is communicated through the Authorization-Lifetime AVP > in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. > > Mobile Node Foreign Agent AAAF AAAH Home Agent > ----------- ------------- ------------ ---------- ---------- > Advertisement & > <--------- Challenge > > Reg-Req&MN-AAA ----> > > AMR------------> > Session-Id = foo > > AMR------------> > Session-Id = foo > > HAR-----------> > Session-Id = bar > > <----------HAA > Session-Id = bar > > <-----------AMA > Session-Id = foo > > <------------AMA > Session-Id = foo > > <-------Reg-Reply > > Figure 2: Mobile IP/Diameter Message Exchange > > The foreign agent (as shown in Figure 2) MAY provide a challenge, > which gives it direct control over the replay protection in the > Mobile IP registration process, as described in [MIPCHAL]. The > mobile node includes the Challenge and MN-AAA authentication > extension to enable authorization by AAAH. If the authentication data > supplied in the MN-AAA extension is invalid, AAAH returns the > response (AMA) with the Result-Code AVP set to > DIAMETER_AUTHENTICATION_REJECTED. > > A mobile node, which has been previously authenticated andauthorized, > MUST always include the assigned home agent in the HA-NAI > and the authorizing Home AAA server in the AAAH-NAI in the > registration request message [AAANAI] sent to the FA, every time the > Mobile Node needs to re-authenticating. So, in the event that the AMR > generated by the FA is for a session that has was previously > authorized, it MUST include the Destination-Host AVP, with the > identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- > Host AVP the identity of the assigned HA found in the HA-NAI. --> Replace the above paragraph (due to various typos) with: "A mobile node, which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, in the registration request message [AAANAI] which is sent to the FA every time the Mobile Node needs to re-authenticate. So, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and realm of the assigned HA found in the HA-NAI." --> How about appending the following sentence to the above paragraph: "Furthermore, if the Registration Request contains an AAAH-NAI, then the FA sets the AMR's Destination-Realm based on the AAAH's NAI. Otherwise the FA sets the AMR's Destination-Realm based on the MN's NAI. --> And how about adding the following paragraph: "Whenever the mobile node specifies a home agent IP address with a value other than 0.0.0.0 or 255.255.255.255 in a Registration Request, the mobile node MUST also include an HA-NAI which conveys the home agent's identity and realm." The above paragraph makes it clear that, if the MN knows who his HA is, whether generating an initial Reg Req or a handoff Reg Req, the MN must also specify the HA's identity. > If the mobile node was successfully authenticated, the AAAH checks if > the Home Agent was located in the foreign realm, by checking the MIP- > Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. --> Exactly what is the check that the AAAH does with the values of the MIP-Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP, and the Home-Agent-In-Foreign-Network flag? I think too many AVPs are probably being inspected here. Isn't the Home-Agent-In-Foreign-Network flag alone sufficient to make the "HA is in foreign network" determination? --> Do we need the Home-Agent-In-Foreign-Network flag anymore? It seems to be at best redundant, and at worst conflicting. Here's what I mean: As I understand it, the Home-Agent-In-Foreign-Network flag would be set by an AAAF if and only if: (a) the FA's AMR contained a MIP-HA-Host AVP, and (b) the HA's realm (from the MIP-HA-Host AVP) is different from the MN's home realm (from the AMR's Destination-Realm AVP). But the AAAH, when processing an AMR which contains a MIP-HA-Host AVP, could just as easily check the HA's realm against his own, as to inspect the Home-Agent-In-Foreign-Network flag (and the other two AVPs mentioned above). And wouldn't have to worry about conflicting information. > If home agent is located in the foreign realm, then AAAH sends an HAR ^ ^ If the home agent is located in the foreign realm, then the AAAH ... > message to the home agent, which contains a MIP-Reg-Request AVP. > > If the home agent was not located in the foreign realm, the AAAH > checks for the MIP-Home-Agent-Address AVP and if present the MIP- > Home-Agent-Host AVP. If one was specified, the AAAH checks that the > address is that of a known home agent and that the Mobile Node is > allowed to request this particular home agent, and that the home > agent's identity is included in the MIP-Home-Agent-Host AVP. If no > home agent was specified, and if the MIP-Feature-Vector has the Home- > Agent-Requested flag set, and if allowed by policy in the home realm, > the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. > This can be done in a variety of ways, including using a load > balancing algorithm in order to keep the load on all home agents > equal. The actual algorithm used and the method of discovering the > home agents is outside the scope of this specification. > > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains > the Mobile IP Registration Request message data encapsulated in the > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The > AAAH MAY allocate a home address for the mobile node, while the Home > Agent MUST support home address allocation. In the event the AAAH > handles address allocation, it includes it in a MIP-Mobile-Node- > Address AVP within the HAR. The absence of this AVP informs the Home > Agent to perform the allocation. > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see Figure 2). If the > AAAH is session-stateful, it MUST send the same session identifier > for all HARs initiated on behalf of a given mobile node's session. > Otherwise, if the AAAH is session-stateless, it will manufacture a > unique session-id for every HAR. > > A mobile node's session is identified via its identity in the User- > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > AVPs. This is necessary in order to allow the session state machine, > defined in the base protocol [DIAMBASE], to be used unmodified with > this application. Therefore, an STR from a foreign agent would free > the session from the foreign agent, but not the one towards the home > agent (see figure 3). > > STR, Session-Id = foo STR, Session-Id = bar > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > STA, Session-Id = foo STA, Session-Id = bar > Figure 3: Session Termination and Session Identifiers > > Upon receipt of the HAR, the home agent first processes the Diameter > message. The home agent processes the MIP-Reg-Request AVP and creates > the Registration Reply, encapsulating it within the MIP-Reg-Reply > AVP. In the creation of the Registration Reply the Home Agent must > include the HA NAI and the AAAH NAI, which will be created from the > Originating-Host AVP and Originating-Realm AVP of the HAR. If a home ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ Origin-Host AVP and Origin-Realm AVP of the HAR. If a home > address is needed, the home agent MUST also assign one and include > the address in both the Registration Reply and within the MIP-Mobile- > Node-Address AVP. > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > returned to the AAAH. Since this is a RADIUS attribute, it'd be a good idea to retain the RADIUS name, i.e. "Acct-Multi-Session-Id". > Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > (AMA) message, includes the Accounting-Multi-Session-Id that was > present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- > Address AVPs in the AMA message, enabling appropriate firewall > controls for the penetration of tunneled traffic between the Home > Agent and the Mobile Node. > > The AAAF is responsible for ensuring that the AMA message is properly > forwarded to the correct foreign agent. Since Answers always take the reverse path of Requests, I don't think the previous paragraph is necessary. > > 1.3 Support for Mobile IP Handoffs > > Given the nature of Mobile IP, a mobile node MAY receive service from > many foreign agents during a period of time. However, the home realm > should not view these handoffs as different sessions, since this > could affect billing systems. Furthermore, many foreign agents do not > communicate, which makes it quite difficult for AAA information to be > exchanged between these entities. Therefore, it MUST be assumed that > a foreign agent is not aware that a registration request from a > mobile node has been previously authorized. > > The first registration request from a mobile node will therefore > cause an AMR to be sent to its AAAF. The AMR will include a new > session identifier, and MAY even be sent to a different AAAF in the > visited network. However, with the usage of the AAA NAI, this AMR is > guaranteed to be received by the AAAH to which the user is currently > registered. I don't like the first sentence of the above paragraph because it talks about the "first registration request" and "a different AAAF". That is, how can there be a different AAAF yet involved if this is only the first registration request? Maybe it would be clearer to rephrase this sentence as follows: "A handoff registration request from a mobile node will cause an AMR to be sent to its AAAF. The AMR will include a new session identifier, and MAY be sent to an AAAF in the visited network other than the AAAF which received the previous AMR." > Since the AAAH may be session-stateless, it is necessary for the > resulting HAR received by the HA to be identified as a continuation > of an existing session. If the HA receives an HAR for a mobile node, > with a new session identifier, and the HA can guarantee that this > request is to extend service for an existing service, then the HA > MUST be able to modify its internal session state information to > reflect the new session identifier. > > It is necessary for accounting records to have some commonality > across handoffs in order for correlation to occur. Therefore, the > home agent MUST send the same Accounting-Multi-Session-Id AVP value > in all HAAs for the mobile's session. That is, the HA generates a > unique Accounting-Multi-Session-Id when receiving an HAR for a new > session, and returns this same value in every HAA for the session. > This Accounting-Multi-Session-Id AVP will be returned to the foreign > agent by the AAAH in the AMA. Both the foreign and home agents MUST > include the Accounting-Multi-Session-Id in the accounting messages. > > ACR, Session-Id = foo ACR, Session-Id = bar > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > > > 1.4 Allocation of Home Agent in Foreign Network > > The Diameter Mobile IP application allows a home agent to be > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > When a foreign agent detects that the mobile node has a home agent > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > Request message, it MUST add a MIP-Feature-Vector AVP with the Home- > Agent- Requested flag set to one. If the home agent address is equal > to 255.255.255.255, then the foreign agent also MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the Home-Agent-Requested > flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm > flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available > flag in the MIP-Feature-Vector AVP to inform the AAAH that it is > willing and able to assign a Home Agent for the Mobile Node. When > doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP > and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- --> How about renaming this AVP from MIP-Originating-Foreign-AAA to MIP-Origin-Foreign-AAA? This is consistent with the names of the existing "Origin-Host" and "Origin-Realm" AVPs, and we won't have to worry about mixing up "Originating" and "Origin". --> I also like the idea of the the originating AAAF *always* including his identity in an AMR, whether including a Candidate-MIP-HA or not. This has two virtues: 1. The AAAH and HA always have a fixed place to look for the FA's identity. 2. The AAAH can be assured that the AMR has actually passed through an AAAF on the way, and thus that the foreign network had its opportunity to apply its policy. What I mean is this: When the FA sends an AMR, it is routed by Destination-Realm. Suppose the FA has a Relay between itself and the local AAAF. The FA sends the AMR to the Relay. If the Relay's routing is misconfigured, the Relay may just route the AMR directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA AVP was required but not present, this would tip off the AAAH that something was amiss. > Agent-Host AVP contains the identity of the home agent that would be > assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > contains the identity of the AAAF. > > In the event that the mobile node has been previously authorized by > the AAAH and now needs to be re-authenticated, and requests to keep > the assigned home agent in the foreign network, the mobile node MUST > include the HA NAI and the AAAH NAI in the registration request to > the FA. Upon receipt, the FA will in create the AMR including the ^^ the FA. Upon receipt, the FA will create the AMR including the > MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the > AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include > the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF > authorizes the use of the requested home agent, the AAAF MUST set the > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. --> This is a good place to add a paragraph that defines the exact test that the AAAF does to make the "HA-is-in-Foreign-Network" determination. If keeping the Home-Agent-In-Foreign-Network flag, then add the paragraph: "The Home-Agent-In-Foreign-Network flag is set by the AAAF if: (a) the FA's AMR contains a MIP-HA-Host AVP, and (b) the HA's realm (from the MIP-HA-Host AVP) is different from the MN's home realm (from the AMR's Destination-Realm AVP)." Or, if eliminating the Home-Agent-In-Foreign-Network flag (my preference), but wanting to specify how an AAA server would make the "HA-is-in-Foreign-Network" determination, add the following paragraph: "An AAA server concludes that the HA is in a foreign network if: (a) the FA's AMR contains a MIP-HA-Host AVP, and (b) the HA's realm (from the MIP-HA-Host AVP) is different from the MN's home realm (from the AMR's Destination-Realm AVP)." --> Question: Because of subrealms, is it sufficient that the HA's realm be merely *different* from the MN's home realm, or does the test need to instead specify matching of trailing substrings? That is, could the MN's NAI be "fred@gm.com" while the AAAH's NAI is "aaah86@buick.gm.com"? > When the AAAH receives an AMR message, it first checks the > authentication data supplied by the mobile node, according to the > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > to authorize the mobile node. If the AMR indicates that the AAAF has > offered to allocate a Home Agent for the mobile node, i.e. the > Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or > the AMR indicates that the AAAF has offered a previously allocated > Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- > Network is set in the MIP-Feature-Vector AVP, then the AAAH must > decide whether its local policy would allow the user to have a Home > Agent in the foreign network or to keep the Home Agent in the foreign > network. If so, and after checking authorization from the data in the > AMR message, the AAAH sends the HAR message to Home Agent byincluding ^ AMR message, the AAAH sends the HAR message to Home Agent by including > the Destination-Host AVP set to the value found in the > AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if > the HA has been previously allocated and authorized by the AAAH. If > the HA has not been previously allocated by the foreign domain, the > HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. > > The HAR sent by the AAAH back to the foreign realm with the > Destination-Host AVP set to the home agents identity, may not > necessarily be received by the same AAAF, which sent the AMR. > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA > AVP from the AMR message to the HAR message. In cases when another > AAAF receives the HAR, the new AAAF will use the MIP-Originating- > Foreign-AAA AVP for policy decisions, such as determining if the FA- > HA Key should be encrypted or not. If on the other hand, the AAAH > local policy determines that the MN-HA Key and the MN-FA Key must be > encrypted and no security association is known to the home agent, the Does "...no security association is known to the home agent" mean that the AAAH has no pre-existing SA with the specified HA? > AAAH SHOULD send the HAR to the originating AAAF by including the > Destination-Host AVP set to the value found in the AMR's MIP- > Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or > the MIP-Candidate-Home-Agent-Host AVP found in the AMR. Probably my fault, but I'm confused. 1. It looks like sometimes the HAR is sent with a Destination-Host set to the HA's identity, and other times with the Destination-Host set to an AAAF's identity. 2. I also get confused trying to understand the context under discussion in some of these paragraphs, i.e. if this is the initial AMR for a session with a candidate foreign-HA, or if this is a handoff for a session with an established foreign-HA in the same visited network, or if this is a handoff into a new network for a session with an established foreign-HA in a previously-visited network But what I will do is to re-read this stuff, and send a separate email with more specific questions and suggestions. > Visited Home > Realm Realm > +--------+ ------- AMR -------> +--------+ > | AAAF | <------ HAR -------- | AAAH | > | | | | > +--->| server | ------- HAA -------> | server | > | +--------+ <------ AMA -------- +--------+ > | ^ | > | | | > HAR/HAA | AMR | | AMA > v | v > +---------+ +---------+ > | Home | | Foreign | > | Agent | | Agent | > +---------+ +---------+ > ^ > +--------+ | > | Mobile |<----------+ > | Node | Mobile IP > +--------+ > Figure 5: Home Agent allocated in Visited Realm > > Upon receipt of a HAA from the Home Agent in the visited realm, the > AAAF forwards the HAA to the AAAH in the home realm. The AMA is then > constructed, and issued to the AAAF, and finally to the FA. If the > Result-Code indicates success, the HAA and AMA MUST include the MIP- > Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > > Mobile Node Foreign Agent Home Agent AAAF AAAH > ----------- ------------- ------------- ---------- ---------- > > <----Challenge---- > Reg-Req (Response)-> > ------------AMR-------------> > -----AMR----> > <----HAR----- > <-----HAR------ > ------HAA------> > -----HAA----> > <----AMA----- > <-------------AMA------------ > <---Reg-Reply---- > Figure 6: Mobile IP/Diameter Message Exchange > > If the Mobile Node moves to another Foreign Network, it MAY either > request to keep the same Home Agent within the old foreign network, > or request to get a new one in the new foreign network. If the AAAH > is willing to provide the requested service, the mobile node will > have to be serviced by two AAAFs. > > Figure 7 shows the message flows for a Mobile Node requesting to keep > the Home Agent assigned in Foreign network 1 when it moves to foreign > network 2. Upon reception of the AMR in Foreign network 2, the AAAF > follows the procedures described earlier and forwards AMR to the > Mobile Node's home network, i.e. its AAAH. If the Mobile Node was > successfully authenticated, the AAAH checks the identity of the > foreign and home agent to determine whether the user is in a third > realm. If this is the case, the AAAH must check whether the mobile is > still permitted to use the previously assigned Home Agent. > > +---------------+ +---------------+ +-------------+ > |Foreign net 2 | |Foreign net 1 | |Home network | > | | | | | | > Mobile Node | FA AAAF | | HA AAAF | | AAAH | > ----------- | ---- ---- | | ---- ------ | | ------ | > +---------------+ +---------------+ +-------------+ > > <----Challenge---- > Reg-Req (Response)-> > ---AMR---> > ----------------AMR---------------> > <-----HAR----- > <---HAR---- > ----HAA---> > ------HAA----> > <---------------AMA---------------- > <--AMA---- > <----Reg-Reply----- > Figure 7: Request to access Home Agent from new Foreign Network > > If the mobile node is allowed to keep the home agent the AAAH then > sends a HAR, which contains the Mobile IP Registration Request > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > Home-Agent-Address AVP with home agent address, as well as any > optional KDC session keys, to the AAAF in foreign network 1. > > Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA > AVP from AMR and include it in the HAR when a third foreign domain is > involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP > for policy decisions, such as determining if the FA-HA Key should be > encrypted or not. Upon reception the AAAF in foreign network 1 will > forward the HAR to the Home Agent if its local policy allows such > service. If the AAAF does not permit such service, it MUST return a > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > If the AAAH local policy determines that the MN-HA Key must be > encrypted and no security association is known to the home agent, the > AAAH MUST send the HAR to the AAAF in foreign network 1, which > originally assigned the HA in foreign network 1, by including its > identity in the Destination-Host AVP. > > When the AAAF receives a HAA, the AAAF will forward the HAA back to > the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- > Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send > back an AMA to the AAAF in foreign network 2. > > If the old Foreign Network does not permit the use of its Home Agent > when the Mobile Node moves to a new foreign network, the AAAH or AAAF > MUST return an AMA with the Result-Code AVP set to > DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the > Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile > Node with an appropriate error. The Mobile Node MAY attempt to > request that a new Home Agent and Address be allocated. When the AAAH > transmits such an error, it MUST issue a Diameter Abort-Session- > Request message to the Home Agent to enable it to release any > resources. " > > Added to section 2.1 AA-Mobile-Node-Request: > > "2.1 AA-Mobile-Node-Request > > The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field > set to 260 and the 'R' bit set in the Command Flags field, is sent by > an attendant, acting as a Diameter client, to a server in order to > request the authentication and authorization of a Mobile Node. The > Foreign Agent (or Home Agent in the case of a co-located Mobile Node) > uses information found in the Registration Request to construct the > following AVPs that are to be included as part of the AMR: > > ... > home agent NAI (MIP-Home-Agent-Host AVP) > home AAA server NAI (Destination-Host AVP [DIAMBASE]) > > ... > > If the mobile node includes the home agent NAI and the home AAA > server NAI [AAANAI], the foreign agent MUST include the MIP-Home- > Agent-Host AVP and the Destination-Host AVP in the AMR. > > ..." > > Added to section 4.0: > > " > MIP-Home-Agent 348 4.12 Grouped | M | P | | V | Y | > Host | | | | | | > " > > > > Added a new grouped AVP: > > "4.12 MIP-Home-Agent-Host AVP > > The MIP-Home-Agent-Host AVP (AVP Code TBD)if of type Grouped, > and contains the identity of the assigned Home Agent. > If present in the AMR, the AAAH MUST copy the MIP-Home-Agent-Host > AVP into the HAR. > > MIP-Home-Agent-Host ::= < AVP Header: 348 > > { Destination-Realm } > { Destination-Host } > * [ AVP ] " > It is a little odd to be using "Destination-Realm" and "Destination-Host" as the member AVPs of this MIP-Home-Agent-Host grouped AVP. --> I like the idea of creating three generic AVPs, called "Host-Identity" and "Host-Realm" and "Host-IP-Address". These AVPs would be members of a grouped AVP which can carry the identity information for one of the participants in the mobile session. e.g. MIP-Originating-Foreign-AAA ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Candidate-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Foreign-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } [ Host-IP-Address ] And then eliminating the non-grouped AVPs which purport to carry the all you need to know about a node, but actually carry only the identity but not the realm. I may fire this off as a separate issue and see how it flies. > Added new text to section 5.3 : > > " 5.3 Distributing the Mobile-Home Session Key > > ... > > If the home agent is in the home realm, then AAAH can directly encode > the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include > that AVP in the HAR message for delivery to the home agent. > > If, on the other hand, the home agent is to be allocated in the > visited realm, the AAAH transmits the HAR to the foreign home agent, > where, prior to delivery to the home agent, it is perused by the AAAF > hosting the home agent. If the session key needs to be encrypted the > AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data > AVP using the security association with the home agent or with the > AAAF associated with the home agent. If no security association is > known the home agent, the AAAH will check if a security association > can be established using DSA messages defined in the CMS application > [CMS] with the originating host found in the MIP-Originating-Foreign- > AAA AVP and if the DSA establishment is successful, the AAAH will > encrypt the MIP-HA-to-MN Key AVP with the established security > association. On the other hand, if no security association exists and > the DSA establishment fails, the AAAH MUST return a Result-Code AVP > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > ... " > From owner-aaa-wg@merit.edu Wed Apr 3 14:36:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13578 for ; Wed, 3 Apr 2002 14:36:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B73889129B; Wed, 3 Apr 2002 14:36:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86D179129C; Wed, 3 Apr 2002 14:36:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CA799129B for ; Wed, 3 Apr 2002 14:36:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 411BD5DDCD; Wed, 3 Apr 2002 14:36:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F0A475DDC5 for ; Wed, 3 Apr 2002 14:36:41 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B449E6C; Wed, 3 Apr 2002 14:36:41 -0500 (EST) From: "Bob Kopacz" To: "John Loughney" , "Tony Johansson" , "David Spence" Cc: "aaa-wg" Subject: [AAA-WG]: [issue]: New generic host identification AVPs Date: Wed, 3 Apr 2002 14:35:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : New generic host identification AVPs Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 04-03-2002 Reference: Document: Base-10, Mobile-IPv4-10 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In the Mobile IPv4 draft, there are various AVPs which carry the identity, or identity+realm, of the various participants in a mobile session. The current plus proposed AVPs are: - MIP-Home-Agent-Host ::= < Grouped AVP:... > { Destination-Realm } { Destination-Host } * [ AVP ] - MIP-Home-Agent-Address AVP = IP address of HA - MIP-Originating-Foreign-AAA ::= < Grouped AVP:... > { Origin-Realm } { Origin-Host } * [ AVP ] - MIP-Candidate-Home-Agent-Host = diameter identity of candidate HA - MIP-Foreign-Agent-Host = diameter identity of FA The existing set of identification AVPs has become muddled: Sometimes the realm is part of the information, sometimes the realm is inferred from other information. The IP address information is carried separately from the identity. And the original meaning of the existing Destination-xxx and Origin-xxx AVPs has been overloaded so that new AVPs needn't be created. Requested Change: 1. Create three generic AVPs, called "Host-Identity" and "Host-Realm" and "Host-IPv4-Address", which are intended to be member AVPs of a grouped AVP. Define these AVPs in the Base document, right after the 6.x sections which define the Origin-xxx and Destination-xxx AVPs. The reason for putting these in the Base document is so that they are made available to other applications. "6.x Host-Identity AVP "The Host-Identity AVP (AVP Code TBD) is of type DiameterIdentity and contains the identity of a Diameter agent. This AVP is intended to be a member of a grouped AVP which carries a collection of Diameter identification information for a Diameter node. "6.x Host-Realm AVP "The Host-Identity AVP (AVP Code TBD) is of type UTF8String and contains the realm of a Diameter agent. This AVP is intended to be a member of a grouped AVP which carries a collection of Diameter identification information for a Diameter node. "6.x Host-IPv4-Address AVP "The Host-IPv4-Address AVP (AVP Code TBD) is of type IPAddress and contains the IPv4 address of a Diameter agent. This AVP is intended to be a member of a grouped AVP which carries a collection of Diameter identification information for a Diameter node." 2. In the Diameter Mobile IPv4 draft, redefine the AVPs which carry the identification information for the participants in the mobile session, as follows: MIP-Originating-Foreign-AAA ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Candidate-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Foreign-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } MIP-Home-Agent ::= < AVP Header:... > { Host-Realm } { Host-Identity } [ Host-IPv4-Address ] From owner-aaa-wg@merit.edu Wed Apr 3 16:22:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16109 for ; Wed, 3 Apr 2002 16:22:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D17D9912A6; Wed, 3 Apr 2002 16:21:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D153912AA; Wed, 3 Apr 2002 16:21:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8312B912A6 for ; Wed, 3 Apr 2002 16:21:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6804F5DDB7; Wed, 3 Apr 2002 16:21:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id D6C895DD98 for ; Wed, 3 Apr 2002 16:21:30 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g33LLUl23563; Wed, 3 Apr 2002 15:21:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g33LLTj11448; Wed, 3 Apr 2002 15:21:29 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA11705; Wed, 3 Apr 2002 15:21:29 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA26385; Wed, 3 Apr 2002 15:21:28 -0600 (CST) Message-ID: <3CAB71AB.365E330@ericsson.com> Date: Wed, 03 Apr 2002 13:18:35 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, There will be a conference call next week with IESG regarding normative dependencies on CMS within the Diameter Base, NASREQ, and MIP documents. So, we have to wait and see the outcome from that meeting.. /Tony Bob Kopacz wrote: > Hi Tony, > > I'm looking over your proposed solution to issues #299 and #301. > > Issue#301 has to do with how to distribute AAAH-generated session keys > securely, and up to now this has relied on CMS. As does the resolved > issue#266, on securely distributing an AAAF-generated FA-HA-Key, when > there is a foreign HA. > > But I'm confused about CMS. That is, my understanding is that CMS is > being held back, and that the Mobile IPv4 draft, and others, will move > ahead without CMS. > > Here's some questions, so I can give you better feedback: > > Q1: Is it true that terms like "CMS" and "DSA" and "end-to-end security" > shouldn't be part of the current Mobile IPv4 draft? > > Q2: If so, then is issue#301 being shelved for the time being? And the > Mobile IPv4 draft will say something like "the only currently-available > security for session keys is TLS". > > Q3: When CMS does come out, is the game plan to then update and release > a new Mobile IPv4 RFC, with CMS security for session keys, and solutions > for issues#266 and #301? Or is the plan that the CMS RFC will include > information about how Mobile IPv4 can use CMS to hide session keys, so > that the Mobile IPv4 RFC won't require updating? > > Thanks, > Bob K. From owner-aaa-wg@merit.edu Wed Apr 3 21:22:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21390 for ; Wed, 3 Apr 2002 21:22:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4895E912A1; Wed, 3 Apr 2002 21:21:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18353912A3; Wed, 3 Apr 2002 21:21:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C37EE912A1 for ; Wed, 3 Apr 2002 21:21:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2B9F5DDE7; Wed, 3 Apr 2002 21:21:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 464475DDA2 for ; Wed, 3 Apr 2002 21:21:46 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g342Lji27785; Wed, 3 Apr 2002 20:21:45 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g342LjO17590; Wed, 3 Apr 2002 20:21:45 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id UAA07657; Wed, 3 Apr 2002 20:21:44 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA01803; Wed, 3 Apr 2002 20:21:43 -0600 (CST) Message-ID: <3CABB80A.1DCC1BA@ericsson.com> Date: Wed, 03 Apr 2002 18:18:50 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, Thanks for your veeery loooong mail ;-) Please, find my comments inline... /Tony Bob Kopacz wrote: > Hi Tony, > > I'm confused on a few points, so I hope you'll bear with me. > > Most of my comments are focused on issue#299: handling handoffs. > > I'll send separate comments more focused on issue#301: securing > session keys. > > I've tagged my specific suggestions with "-->". > > Bob K. > > > -------- Original Message -------- > > Subject: Issue #299 and #301 > > Date: Mon, 01 Apr 2002 11:53:07 -0800 > > From: Tony Johansson > > To: aaa-wg@merit.edu > > > > All, > > > > I have worked on new proposed text for issue 299 and 301, see below, > > based on the solution we agree upon at the IETF 53. Part of this > > solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines > > the needed AAAH NAI and the HA NAI, please see > > http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt. > > The draft have been submitted to the mobileip wg and will go to wg final > > call if no major comments/issues are found on the mobileip wg list. > > > > I hope this solves the issue 299 and 301, however I need help to > > understand how I should deal the newly submitted issue #321 regarding > > CMS. Is it good enough to just move the CMS ref to informative? > > > > Comments please. > > > > /Tony > > > > > > > > Added to to section 1.0: > > > > "1.0 Introduction > > > > ... > > > > Furthermore, the nature of mobile IP also means that the mobile node > > will do handoffs between different foreign agents and to guarantee > > that a registered user always ends up in the same initial AAAH the > > Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to > > assist the AAAH in routing the messages to a mobile node's home agent > > the mobile node MUST always include the HA NAI [AAANAI]. > > --> How about changing the tail of the first sentence to "the Mobile > Node, upon changing his point of attachment for a given session, MUST > include the home NAI and the AAAH NAI [AAANAI]". Just to make it clear > that the AAAH NAI information isn't required in the initial Registration > Request of a session. > This is explicitly stated in [AAANAI], so I don't see why we need to repeat that in this draft. > > --> How about changing the second sentence to: "Finally, to assist the > AAAH in routing the messages to a mobile node's home agent the mobile > node MUST include the HA NAI [AAANAI], if including an HA IP address > other than 0.0.0.0 or 255.255.255.255" See comment above, will be stated in -01. > > > --> The plan, then, is that exactly one AAAH will be employed for the > life of a MN's session. And if that AAAH becomes unavailable, it is > "game over" for the MN's session, even if other AAAHs are available? The protocol doesn't mention this, since this capability may be provided by an implementation outside the scope of this protocol. > > > > ... " > > > > I've made changes here and there in section 1.2, 1.3 and 1.4, so here is > > the whole text... > > > > " 1.2 Inter-Realm Mobile IP > > > > When a Mobile Node node requests service by issuing a Registration > > Request to the foreign agent, the foreign agent creates the AA- > > Mobile-Node-Request (AMR) message, which includes the AVPs defined in > > section 2.1. The Home Address, Home Agent, Mobile Node NAI and other > > important fields are extracted from the registration messages for > > possible inclusion as Diameter AVPs. The AMR message is then > > forwarded to the local Diameter server, known as the AAA-Foreign, or > > AAAF. > > > > Visited Realm Home Realm > > +--------+ +--------+ > > |abc.com | AMR/AMA |xyz.com | > > | AAAF |<------------------->| AAAH | > > +->| server | server-server | server | > > | +--------+ communication +--------+ > > | ^ ^ > > | AMR/AMA | client-server | HAR/HAA > > | | communication | > > v v v > > +---------+ +---------+ +---------+ > > | Foreign | | Foreign | | Home | > > | Agent | | Agent | | Agent | > > +---------+ +---------+ +---------+ > > ^ > > | Mobile IP > > | > > v > > +--------+ > > | Mobile | > > | Node | mn@xyz.com > > +--------+ > > Figure 1: Inter-Realm Mobility > > > > Upon receiving the AMR, the AAAF follows the procedures outlined in > > [DIAMBASE] to determine whether the AMR should be processed locally, > > or if it should be forwarded to another Diameter server, known as the > > AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node > > (mn@xyz.com) requests service from a foreign provider (abc.com). The > > request received by the AAAF is forwarded to xyz.com's AAAH server. > > > > Figure 2 shows the message flows involved when the foreign agent > > invokes the AAA infrastructure to request that a mobile node be > > authenticated and authorized. Note that it is not required that the > > foreign agent invoke AAA services every time a Registration Request > > is received from the mobile, but rather only when the prior > > authorization from the AAAH expires. > > The last sentence, beginning "Note that...", either needs more > clarification, or maybe should be striken. > > For example, how (what is the algorithm by which) does the FA determine > whether or not to invoke AAA services? The details are specified in RFC3012. > > > Also, for example, doesn't this sentence conflict with the last sentence > of the first paragraph of section 1.3, which says that "Therefore, it > MUST be assumed that a foreign agent is not aware that a registration > request from a mobile node has been previously authorized." > > Also, wouldn't there be other reasons for the FA to invoke AAA services, > beyond "*only* when the prior authorization from the AAAH expires". > E.g, the authorization might not have expired, but maybe the new FA > needs an FA-xx key. Or the key lifetime is approaching expiration. Again, you will find some of the details in RFC3012. In brief, if the MN has no SA to the FA the MN must include the MN-AAA auth ext. This could e.g. happen if MN does a handoff to a new FA where no session keys are known or if the session keys have expired.. Also, section 5.5.1 Authorization Lifetime vs. MIP Key Lifetime in in Diameter mipv4 appl explains the two timers used in mip, which my trigger this behavior. > > > --> I would suggest either striking the "Note that..." sentence > altogether, or trimming it to "It is not required that the foreign agent > invoke AAA services every time a Registration Request is received from > the mobile". > > > The expiration time of the > > authorization is communicated through the Authorization-Lifetime AVP > > in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. > > > > Mobile Node Foreign Agent AAAF AAAH Home Agent > > ----------- ------------- ------------ ---------- ---------- > > Advertisement & > > <--------- Challenge > > > > Reg-Req&MN-AAA ----> > > > > AMR------------> > > Session-Id = foo > > > > AMR------------> > > Session-Id = foo > > > > HAR-----------> > > Session-Id = bar > > > > <----------HAA > > Session-Id = bar > > > > <-----------AMA > > Session-Id = foo > > > > <------------AMA > > Session-Id = foo > > > > <-------Reg-Reply > > > > Figure 2: Mobile IP/Diameter Message Exchange > > > > The foreign agent (as shown in Figure 2) MAY provide a challenge, > > which gives it direct control over the replay protection in the > > Mobile IP registration process, as described in [MIPCHAL]. The > > mobile node includes the Challenge and MN-AAA authentication > > extension to enable authorization by AAAH. If the authentication data > > supplied in the MN-AAA extension is invalid, AAAH returns the > > response (AMA) with the Result-Code AVP set to > > DIAMETER_AUTHENTICATION_REJECTED. > > > > A mobile node, which has been previously authenticated andauthorized, > > MUST always include the assigned home agent in the HA-NAI > > and the authorizing Home AAA server in the AAAH-NAI in the > > registration request message [AAANAI] sent to the FA, every time the > > Mobile Node needs to re-authenticating. So, in the event that the AMR > > generated by the FA is for a session that has was previously > > authorized, it MUST include the Destination-Host AVP, with the > > identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- > > Host AVP the identity of the assigned HA found in the HA-NAI. > > --> Replace the above paragraph (due to various typos) with: > > "A mobile node, which has been previously authenticated and authorized, > MUST always include the assigned home agent in the HA Identity subtype > of the AAA NAI extension, and the authorizing Home AAA server in the > AAAH Identity subtype of the AAA NAI extension, in the registration > request message [AAANAI] which is sent to the FA every time the Mobile > Node needs to re-authenticate. So, in the event that the AMR generated > by the FA is for a session that was previously authorized, it MUST > include the Destination-Host AVP, with the identity of the AAAH found in > the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and > realm of the assigned HA found in the HA-NAI." Ok. > > > --> How about appending the following sentence to the above paragraph: > > "Furthermore, if the Registration Request contains an AAAH-NAI, > then the FA sets the AMR's Destination-Realm based on the AAAH's NAI. > Otherwise the FA sets the AMR's Destination-Realm based on the MN's > NAI. > > --> And how about adding the following paragraph: > > "Whenever the mobile node specifies a home agent IP address with a value > other than 0.0.0.0 or 255.255.255.255 in a Registration Request, the > mobile node MUST also include an HA-NAI which conveys the home agent's > identity and realm." This is specified in [AAANAI]. > > > The above paragraph makes it clear that, if the MN knows who his HA is, > whether generating an initial Reg Req or a handoff Reg Req, the MN must > also specify the HA's identity. > > > If the mobile node was successfully authenticated, the AAAH checks if > > the Home Agent was located in the foreign realm, by checking the MIP- > > Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the > > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. > > --> Exactly what is the check that the AAAH does with the values of the > MIP-Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP, and the > Home-Agent-In-Foreign-Network flag? I think too many AVPs are probably being > inspected here. Isn't the Home-Agent-In-Foreign-Network flag alone > sufficient to make the "HA is in foreign network" determination? No - checking this flag alone does not provide the capability of determining that there may be more than one foreign network involved. > > > --> Do we need the Home-Agent-In-Foreign-Network flag anymore? It seems > to be at best redundant, and at worst conflicting. Here's what I mean: > > As I understand it, the Home-Agent-In-Foreign-Network flag would be set > by an AAAF if and only if: > (a) the FA's AMR contained a MIP-HA-Host AVP, and > (b) the HA's realm (from the MIP-HA-Host AVP) is different from the > MN's home realm (from the AMR's Destination-Realm AVP). > > But the AAAH, when processing an AMR which contains a MIP-HA-Host AVP, > could just as easily check the HA's realm against his own, as to inspect > the Home-Agent-In-Foreign-Network flag (and the other two AVPs mentioned > above). And wouldn't have to worry about conflicting information. > > > If home agent is located in the foreign realm, then AAAH sends an HAR > ^ ^ > If the home agent is located in the foreign realm, then the AAAH ... check. > > > > message to the home agent, which contains a MIP-Reg-Request AVP. > > > > If the home agent was not located in the foreign realm, the AAAH > > checks for the MIP-Home-Agent-Address AVP and if present the MIP- > > Home-Agent-Host AVP. If one was specified, the AAAH checks that the > > address is that of a known home agent and that the Mobile Node is > > allowed to request this particular home agent, and that the home > > agent's identity is included in the MIP-Home-Agent-Host AVP. If no > > home agent was specified, and if the MIP-Feature-Vector has the Home- > > Agent-Requested flag set, and if allowed by policy in the home realm, > > the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. > > This can be done in a variety of ways, including using a load > > balancing algorithm in order to keep the load on all home agents > > equal. The actual algorithm used and the method of discovering the > > home agents is outside the scope of this specification. > > > > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains > > the Mobile IP Registration Request message data encapsulated in the > > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The > > AAAH MAY allocate a home address for the mobile node, while the Home > > Agent MUST support home address allocation. In the event the AAAH > > handles address allocation, it includes it in a MIP-Mobile-Node- > > Address AVP within the HAR. The absence of this AVP informs the Home > > Agent to perform the allocation. > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see Figure 2). If the > > AAAH is session-stateful, it MUST send the same session identifier > > for all HARs initiated on behalf of a given mobile node's session. > > Otherwise, if the AAAH is session-stateless, it will manufacture a > > unique session-id for every HAR. > > > > A mobile node's session is identified via its identity in the User- > > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > > AVPs. This is necessary in order to allow the session state machine, > > defined in the base protocol [DIAMBASE], to be used unmodified with > > this application. Therefore, an STR from a foreign agent would free > > the session from the foreign agent, but not the one towards the home > > agent (see figure 3). > > > > STR, Session-Id = foo STR, Session-Id = bar > > ---------------------> <-------------------- > > +----+ +------+ +------+ +----+ > > | FA | | AAAF | | AAAH | | HA | > > +----+ +------+ +------+ +----+ > > <--------------------- ---------------------> > > STA, Session-Id = foo STA, Session-Id = bar > > Figure 3: Session Termination and Session Identifiers > > > > Upon receipt of the HAR, the home agent first processes the Diameter > > message. The home agent processes the MIP-Reg-Request AVP and creates > > the Registration Reply, encapsulating it within the MIP-Reg-Reply > > AVP. In the creation of the Registration Reply the Home Agent must > > include the HA NAI and the AAAH NAI, which will be created from the > > Originating-Host AVP and Originating-Realm AVP of the HAR. If a home > ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ > Origin-Host AVP and Origin-Realm AVP of the HAR. If a home check. > > > address is needed, the home agent MUST also assign one and include > > the address in both the Registration Reply and within the MIP-Mobile- > > Node-Address AVP. > > > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > > returned to the AAAH. > > Since this is a RADIUS attribute, it'd be a good idea to retain > the RADIUS name, i.e. "Acct-Multi-Session-Id". Good catch. Please make a new issue to the BASE. > > > > Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > > (AMA) message, includes the Accounting-Multi-Session-Id that was > > present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- > > Address AVPs in the AMA message, enabling appropriate firewall > > controls for the penetration of tunneled traffic between the Home > > Agent and the Mobile Node. > > > > The AAAF is responsible for ensuring that the AMA message is properly > > forwarded to the correct foreign agent. > > Since Answers always take the reverse path of Requests, I don't think > the previous paragraph is necessary. Ok. > > > > > > 1.3 Support for Mobile IP Handoffs > > > > Given the nature of Mobile IP, a mobile node MAY receive service from > > many foreign agents during a period of time. However, the home realm > > should not view these handoffs as different sessions, since this > > could affect billing systems. Furthermore, many foreign agents do not > > communicate, which makes it quite difficult for AAA information to be > > exchanged between these entities. Therefore, it MUST be assumed that > > a foreign agent is not aware that a registration request from a > > mobile node has been previously authorized. > > > > The first registration request from a mobile node will therefore > > cause an AMR to be sent to its AAAF. The AMR will include a new > > session identifier, and MAY even be sent to a different AAAF in the > > visited network. However, with the usage of the AAA NAI, this AMR is > > guaranteed to be received by the AAAH to which the user is currently > > registered. > > I don't like the first sentence of the above paragraph because it talks > about the "first registration request" and "a different AAAF". That is, > how can there be a different AAAF yet involved if this is only the first > registration request? Maybe it would be clearer to rephrase this > sentence as follows: > > "A handoff registration request from a mobile node will cause an AMR to > be sent to its AAAF. The AMR will include a new session identifier, and > MAY be sent to an AAAF in the visited network other than the AAAF which > received the previous AMR." Ok. > > > > Since the AAAH may be session-stateless, it is necessary for the > > resulting HAR received by the HA to be identified as a continuation > > of an existing session. If the HA receives an HAR for a mobile node, > > with a new session identifier, and the HA can guarantee that this > > request is to extend service for an existing service, then the HA > > MUST be able to modify its internal session state information to > > reflect the new session identifier. > > > > It is necessary for accounting records to have some commonality > > across handoffs in order for correlation to occur. Therefore, the > > home agent MUST send the same Accounting-Multi-Session-Id AVP value > > in all HAAs for the mobile's session. That is, the HA generates a > > unique Accounting-Multi-Session-Id when receiving an HAR for a new > > session, and returns this same value in every HAA for the session. > > This Accounting-Multi-Session-Id AVP will be returned to the foreign > > agent by the AAAH in the AMA. Both the foreign and home agents MUST > > include the Accounting-Multi-Session-Id in the accounting messages. > > > > ACR, Session-Id = foo ACR, Session-Id = bar > > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > > > > ---------------------> <-------------------- > > +----+ +------+ +------+ +----+ > > | FA | | AAAF | | AAAH | | HA | > > +----+ +------+ +------+ +----+ > > <--------------------- ---------------------> > > ACA, Session-Id = foo ACA, Session-Id = bar > > > > Figure 4: Accounting messages w/ Mobile IP Application > > > > > > 1.4 Allocation of Home Agent in Foreign Network > > > > The Diameter Mobile IP application allows a home agent to be > > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > > When a foreign agent detects that the mobile node has a home agent > > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > > Request message, it MUST add a MIP-Feature-Vector AVP with the Home- > > Agent- Requested flag set to one. If the home agent address is equal > > to 255.255.255.255, then the foreign agent also MUST set the Home- > > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > > agent address is set to 0.0.0.0, the foreign agent MUST set the Home- > > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > > > When the AAAF receives an AMR message with the Home-Agent-Requested > > flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm > > flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available > > flag in the MIP-Feature-Vector AVP to inform the AAAH that it is > > willing and able to assign a Home Agent for the Mobile Node. When > > doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP > > and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- > > --> How about renaming this AVP from MIP-Originating-Foreign-AAA to > MIP-Origin-Foreign-AAA? This is consistent with the names of the > existing "Origin-Host" and "Origin-Realm" AVPs, and we won't have to > worry about mixing up "Originating" and "Origin". > > --> I also like the idea of the the originating AAAF *always* including > his identity in an AMR, whether including a Candidate-MIP-HA or not. > This has two virtues: Ok. I'll change the text to always include the originating AAAF. > > > Agent-Host AVP contains the identity of the home agent that would be > > assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > > contains the identity of the AAAF. > > > > In the event that the mobile node has been previously authorized by > > the AAAH and now needs to be re-authenticated, and requests to keep > > the assigned home agent in the foreign network, the mobile node MUST > > include the HA NAI and the AAAH NAI in the registration request to > > the FA. Upon receipt, the FA will in create the AMR including the > ^^ > the FA. Upon receipt, the FA will create the AMR including the check. > > > > MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the > > AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include > > the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF > > authorizes the use of the requested home agent, the AAAF MUST set the > > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > --> This is a good place to add a paragraph that defines the exact test > that the AAAF does to make the "HA-is-in-Foreign-Network" determination. The protocol provides all the necessary info. It's an implementation specific detail as to how this exact test is performed. > > > If keeping the Home-Agent-In-Foreign-Network flag, then add the > paragraph: > > "The Home-Agent-In-Foreign-Network flag is set by the AAAF if: > (a) the FA's AMR contains a MIP-HA-Host AVP, and > (b) the HA's realm (from the MIP-HA-Host AVP) is different from the > MN's home realm (from the AMR's Destination-Realm AVP)." > > Or, if eliminating the Home-Agent-In-Foreign-Network flag (my > preference), but wanting to specify how an AAA server would make the > "HA-is-in-Foreign-Network" determination, add the following paragraph: > > "An AAA server concludes that the HA is in a foreign network if: > (a) the FA's AMR contains a MIP-HA-Host AVP, and > (b) the HA's realm (from the MIP-HA-Host AVP) is different from the > MN's home realm (from the AMR's Destination-Realm AVP)." > > --> Question: Because of subrealms, is it sufficient that the HA's realm > be merely *different* from the MN's home realm, or does the test need to > instead specify matching of trailing substrings? That is, could the > MN's NAI be "fred@gm.com" while the AAAH's NAI is "aaah86@buick.gm.com"? > > > When the AAAH receives an AMR message, it first checks the > > authentication data supplied by the mobile node, according to the > > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > > to authorize the mobile node. If the AMR indicates that the AAAF has > > offered to allocate a Home Agent for the mobile node, i.e. the > > Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or > > the AMR indicates that the AAAF has offered a previously allocated > > Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- > > Network is set in the MIP-Feature-Vector AVP, then the AAAH must > > decide whether its local policy would allow the user to have a Home > > Agent in the foreign network or to keep the Home Agent in the foreign > > network. If so, and after checking authorization from the data in the > > AMR message, the AAAH sends the HAR message to Home Agent byincluding > ^ > AMR message, the AAAH sends the HAR message to Home Agent by including check. > > > > the Destination-Host AVP set to the value found in the > > AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if > > the HA has been previously allocated and authorized by the AAAH. If > > the HA has not been previously allocated by the foreign domain, the > > HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. > > > > The HAR sent by the AAAH back to the foreign realm with the > > Destination-Host AVP set to the home agents identity, may not > > necessarily be received by the same AAAF, which sent the AMR. > > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA > > AVP from the AMR message to the HAR message. In cases when another > > AAAF receives the HAR, the new AAAF will use the MIP-Originating- > > Foreign-AAA AVP for policy decisions, such as determining if the FA- > > HA Key should be encrypted or not. If on the other hand, the AAAH > > local policy determines that the MN-HA Key and the MN-FA Key must be > > encrypted and no security association is known to the home agent, the > > Does "...no security association is known to the home agent" mean that > the AAAH has no pre-existing SA with the specified HA? Yes. > From owner-aaa-wg@merit.edu Wed Apr 3 21:42:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22674 for ; Wed, 3 Apr 2002 21:42:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C008B912A3; Wed, 3 Apr 2002 21:42:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93B8B912A4; Wed, 3 Apr 2002 21:42:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F647912A3 for ; Wed, 3 Apr 2002 21:42:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5593A5DDF6; Wed, 3 Apr 2002 21:41:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id E5CA75DDA2 for ; Wed, 3 Apr 2002 21:41:42 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g342fQi07665; Wed, 3 Apr 2002 20:41:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g342fQn14369; Wed, 3 Apr 2002 20:41:26 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id UAA09116; Wed, 3 Apr 2002 20:41:25 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA02115; Wed, 3 Apr 2002 20:41:24 -0600 (CST) Message-ID: <3CABBCA7.5986AD26@ericsson.com> Date: Wed, 03 Apr 2002 18:38:31 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: John Loughney , David Spence , aaa-wg Subject: [AAA-WG]: Re: [issue]: New generic host identification AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Consistency is always a good thing and I think this is a good idea. However, this is by all means not necessary changes and we are very close to being done..... So what do others think about this. /Tony Bob Kopacz wrote: > Issue : New generic host identification AVPs > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 04-03-2002 > Reference: > Document: Base-10, Mobile-IPv4-10 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > In the Mobile IPv4 draft, there are various AVPs which carry the > identity, or identity+realm, of the various participants in a mobile > session. > > The current plus proposed AVPs are: > > - MIP-Home-Agent-Host ::= < Grouped AVP:... > > { Destination-Realm } > { Destination-Host } > * [ AVP ] > > - MIP-Home-Agent-Address AVP = IP address of HA > > - MIP-Originating-Foreign-AAA ::= < Grouped AVP:... > > { Origin-Realm } > { Origin-Host } > * [ AVP ] > > - MIP-Candidate-Home-Agent-Host = diameter identity of candidate HA > > - MIP-Foreign-Agent-Host = diameter identity of FA > > The existing set of identification AVPs has become muddled: Sometimes > the realm is part of the information, sometimes the realm is inferred > from other information. The IP address information is carried > separately from the identity. And the original meaning of the existing > Destination-xxx and Origin-xxx AVPs has been overloaded so that new AVPs > needn't be created. > > Requested Change: > > 1. Create three generic AVPs, called "Host-Identity" and "Host-Realm" > and "Host-IPv4-Address", which are intended to be member AVPs of a > grouped AVP. > > Define these AVPs in the Base document, right after the 6.x sections > which define the Origin-xxx and Destination-xxx AVPs. The reason for > putting these in the Base document is so that they are made available > to other applications. > > "6.x Host-Identity AVP > > "The Host-Identity AVP (AVP Code TBD) is of type DiameterIdentity and > contains the identity of a Diameter agent. This AVP is intended to be > a member of a grouped AVP which carries a collection of Diameter > identification information for a Diameter node. > > "6.x Host-Realm AVP > > "The Host-Identity AVP (AVP Code TBD) is of type UTF8String and contains > the realm of a Diameter agent. This AVP is intended to be a member of > a grouped AVP which carries a collection of Diameter identification > information for a Diameter node. > > "6.x Host-IPv4-Address AVP > > "The Host-IPv4-Address AVP (AVP Code TBD) is of type IPAddress and > contains the IPv4 address of a Diameter agent. This AVP is intended to > be a member of a grouped AVP which carries a collection of Diameter > identification information for a Diameter node." > > 2. In the Diameter Mobile IPv4 draft, redefine the > AVPs which carry the identification information for the > participants in the mobile session, as follows: > > MIP-Originating-Foreign-AAA ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Candidate-Home-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Foreign-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Home-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > [ Host-IPv4-Address ] From owner-aaa-wg@merit.edu Thu Apr 4 02:19:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05915 for ; Thu, 4 Apr 2002 02:19:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5D2791206; Thu, 4 Apr 2002 02:18:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71E0E912AB; Thu, 4 Apr 2002 02:18:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6569E91206 for ; Thu, 4 Apr 2002 02:18:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 479DF5DDAC; Thu, 4 Apr 2002 02:18:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 8C7695DDAA for ; Thu, 4 Apr 2002 02:18:52 -0500 (EST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g347JsPQ022105; Thu, 4 Apr 2002 09:20:10 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "Tony Johansson" Cc: "Joe Lau" , "AAA Working Group" Subject: RE: [AAA-WG]: Issue 317:FA-HA Key Date: Thu, 4 Apr 2002 09:16:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sivasundar, Please see comments inline. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Sivasundar Ramamurthy >Sent: den 2 april 2002 18:57 >To: Tony Johansson >Cc: Joe Lau; AAA Working Group >Subject: Re: [AAA-WG]: Issue 317:FA-HA Key > > > >Hello Tony, > >On Mon, 1 Apr 2002, Tony Johansson wrote: > >> But each FA-HA key also has SPI, which helps out to identify the key. >> Thus, when a HA receives a MIP RRQ from the FA, the HA must identify the >> the right FA-HA key to be used by looking at the received FA-HA >SPI in the >> FA-HA auth. > >What I think you are saying is that the HA maintains multiple HA-FA >keys (one for each session?), but can expect the FA to use any of >those keys. The HA authenticates the FA by selecting the key that >matches the SPI used by the FA, even if the key is from a different >session. And in order to make this work, the HA needs to make sure >that each session key has a unique SPI. > >This is different from the two implementations I was referring in my >original email: > >1. The HA implementation maintains only one key to the FA. Everytime >it get a new key to the FA, it will refresh the existing key (if any) >and assign the same SPI to the new key. This is the only key that will >be used for all communication between the FA and HA. (corresponds to >"any key") But this is a illegal behavior, what if the message distributing the keys to the FA gets lost on its way? Consider the case where the HA receives a new key for the FA and refreshes the existing key and assigns the same SPI (as you indicate) to the new key. If the FA does not receive the new key it will try to use the old key which still might be valid since it should request new keys sometime before the old one expires. When the request reaches the HA it will check what key to use by looking at the SPI, the HA will now take the new key since it has already replaced the old one, i.e. you get an authentication failure just beacause the HA replaced the key for that SPI. > >2. The FA implementation maintains HA-FA key for each session, which >is the one and only key that can be used for any communication between >the FA and HA for that session -- the FA will expect the authenticator >from the HA to have been created only using that session's key (and >SPI). (corresponds to "session key"). The FA-HA keys does not have anything todo with the session, the session might just be the one that distributes the key. A Security Association is between a pair of nodes. When the FA should authenticate a mip msg it looks at the SPI to find a Security Context within the Mobility Security Association that exists between the FA and the node that sent the message. It may very well be so that every session adds a new Security Context to the Mobility Security Association, but they are all valid for any session between these nodes. Each Context may have a lifetime similar to that of the session that added it, but there is nothing in the context that tells the FA which session that added it. If one would like to limit the number of keys held at the FA, one can implement a scheme where the FA doesn't request keys to be distributed if it has valid keys. This will be more complex since one has to take care of the case where the new session last longer than the existing keys. > >I dont think there is anything in the draft that says that the above >two interpretations are wrong. Even if it may seem that "multiple Nope, not in the Diameter drafts, but the use is in Mobile IP, Diameter is just used for distribution. >HA-FA keys indexed by SPI" is the correct way to do it, I feel that it >is better if we can make certain issues non-implementation specific to >eliminate chances of unnecessary HA-FA authentication failures. > > >thanks, > >Siva > > > >> /Tony >> >> Sivasundar Ramamurthy wrote: >> >> > Hello Tony, >> > >> > On Mon, 1 Apr 2002, Tony Johansson wrote: >> > >> > > Why would it be interpretability problems ? >> > >> > If the HA and FA folllow different implementations, there might be >> > unnecessary authentication failures. Consider the case when the FA >> > keeps one FA-HA key per session, and the HA keeps one key per FA and >> > uses it for all sessions. If there are multiple MNs of that HA >> > visiting the FA, re-registrations of some MN's may result in in FA-HA >> > authentication failures -- FA is using the key from a specific >> > session, while the HA's "global" key to that FA is obtained from a HAR >> > from another session. >> > >> > Siva >> >> > > >Thanks, > >Siva > > >==================================== >Sivasundar Ramamurthy >(She-va-su-ndar Ra-ma-moor-thee) > >Engineer, Mobile IP Project >Hewlett Packard >(408) 447 7255 >==================================== > > > > From owner-aaa-wg@merit.edu Thu Apr 4 02:42:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06201 for ; Thu, 4 Apr 2002 02:42:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D8B4912AD; Thu, 4 Apr 2002 02:41:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27140912AE; Thu, 4 Apr 2002 02:41:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6741912AD for ; Thu, 4 Apr 2002 02:41:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4A725DDED; Thu, 4 Apr 2002 02:41:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id F17755DDAA for ; Thu, 4 Apr 2002 02:41:42 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g347ff528882 for ; Thu, 4 Apr 2002 10:41:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 10:41:26 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 10:41:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 10:41:26 +0300 Message-ID: <93532512B06FC3489824C18037DB3D4B7B75CD@esebe015.NOE.Nokia.com> Thread-Topic: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbrB/8yd6Fa0eREdaqaQACswWDNA== From: To: , Cc: X-OriginalArrivalTime: 04 Apr 2002 07:41:26.0485 (UTC) FILETIME=[203D9850:01C1DBAC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA06201 Hi, Some comments below. Thanks very much for the discussion. Regards Elena > > Hi, > > > > With regard to the need of having accounting states or not: > > > > 1. According to the definition of the Idle state means " > When a session is moved to the Idle state, any resources that > were allocated for the particular session must be released" > > > This may not be the right text in the accounting side. I'll > take care of rewording this. > Elena: Ok. > > > 2.It should be so that messages arrive in certain order ; > otherwise should be rejected or at least processed > differently.I think that an Interim should be rejected if a > Start was not received before.Otherwise what is the purpose > of the Start anyway if not matter in which order they arrive > the result is exactly the same? So, we would not need start, > interim or stop not even any order in which those should arrive. > > > > So, since there is start , interim and stop and those are > linked to one accounting session there should be session > states which are based on receiving those requests and > sending corresponding responses. > > > > Otherwise, I cannot really understand the purpose of those > different messages if in the end of the day there is only one > state and always the same end result. > > I believe there's a few different issues at play here: > > - Billing vs. just collecting data. At which stage do we make > all the sanity checks and so on? > Is it the task of the data collector (diameter accounting) > or the billing process (some > rather company specific mechanism and policies)? Elena. The purpose should be to make proper data collection part of the diameter accounting off-loading thus the actual billing process. Otherwise, if diameter accounting does not offer proper data collection, needed sanity checks etc then in terms of accounting protocol would not be offering advantages over other accounting /collection mechanisms which do offer some of the above. Shouldn't the purpose of diameter accounting be to offer as reliable data collection as possible already within the protocol layer? Otherwise, relaying on the billing process is something that can be done without Diameter accounting. > > - State of the accounting server vs. real-world effects. > Pretty much the same thing > as above. The state of the diameter accounting server > might not change due to a message > being received, but there might still be a real-world > event, such as my bank account > balance getting (even) smaller because I used a service > and the billing process used > an accounting record from the diameter accounting server > to bill me for it. > Elena: That is correct. There should be the basic state maching "maintained" as part of the accounting session ensuring proper collection, sanity etc. At the same time real-world effects involve several systems and several events which should not affect the basic accounting session state.Basically, the way accounting data is processed, which accounts are affected with monetary /non monetary impacts or what other actions are triggered should not affect the basic state machine(?). > - State vs. records. Accounting service must at least keep > records in some sort of > storage. Sometimes we may want to keep state as well, even > do very complicated things > like fraud detection. But do we need to keep state *always*? Elena: I agree with you that we may not always want to keep state. But when we do not want to keep state then we can easily use a single message e.g. after the service delivery simply to transfere the generated "accounting data". I still do not see the point of having three different messages for a session which never has a state. How is the server supposed to process differently those three different messages if their order does not make any sense? > > My opinion is that we should focus Diameter accounting on the > data collection part, and > allow but not require keeping state. Elena: That should be stated in the doc so that "simple accounting" does not require state but "state related" accounting does require or in some better way ? Otherwise, I cannot really understand the purpose of those different messages if in the end of the day there is only one state and always the same end result. > The difference is the value of one avp that describes which "state" the accounting session is in. Elena: Of course there is difference in the avp but if the server does not maintain any state what is the purpose of the state in which the accounting session is in? How can the server process differently the messages received ? 2.It should be so that messages arrive in certain order ; otherwise should be rejected or at least processed differently. > But it is not possible to guarantee the order in which they arrive even if there is an order in which they are sent, especially not when sending stale records as the result of failure recovery. Elena: I agree that nothing can be guaranteed with regard to the order messages arrive.But should the way the server process the messages be different if they arrive in the correct order or in the wrong order ? If messages get send in any order then Billing process will be quite overloaded just to "short out" dublicate , incorrect data just because the protocol layer does not provide with any proper collection mechanismetc. So, either there is correct order and any messages arriving out of the correct order is marked "differently" or else there is no need to define the correct order at all (?). There is one saying: "Exceptions confirm the rule". But please comment if > you feel differently. In any > case I continue to be happy that Pete's split is revealing > these discussion items! > > Jari From owner-aaa-wg@merit.edu Thu Apr 4 03:12:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06732 for ; Thu, 4 Apr 2002 03:12:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 731E3912B0; Thu, 4 Apr 2002 03:12:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36966912B1; Thu, 4 Apr 2002 03:12:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB3E9912B0 for ; Thu, 4 Apr 2002 03:12:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BAB95DE09; Thu, 4 Apr 2002 03:12:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id C80D05DE07 for ; Thu, 4 Apr 2002 03:12:20 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g3476Pp15959; Thu, 4 Apr 2002 09:06:25 +0200 Message-ID: <3CAC0941.8010105@ipunplugged.com> Date: Thu, 04 Apr 2002 10:05:21 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sivasundar Ramamurthy wrote: >>In any case, the HA does not know which ip >>address to use for it's SA with the FA. >> >>Note that this means that any implementation that assumes that it knows >>how to key the SA is *severly broken*. >> >>I can see 3 different solutions to this problem. >> >> 1. Make the MIP-Foreign-Agent-Host avp a MIP-Foreign-Agent-Address >> avp and make it mandatory in the AMR and HAR. >> > >This will work but might require the FA has to use the same >control interface to forward all reg requests to this HA. This is >needed if the HA has multiple SAs to the same FA and can expect the FA >to use any of these SAs. > The interface could be changed by performing a new Diameter authorization and requesting a new set of keys. >> 2. Since the UDP header is part of the MobileIP protocol, include the >> UDP header in the MIP-Reg-Request avp >> > >This may not work since the AAA authentication will fail for the MN, >unless the header is added after the MN-AAA auth ext (if that makes >sense at all!) > Why would it fail? Obviously, the fact that there is an UDP header present needs to be taken into account whenever the MIP-Reg-Request is used. >> 3. Demand that the CoA is used to key SAs in MobileIP (fat chance - >> but it is a possible solution) >> >Another solution is retaining the FA-Host AVP and having the FA >include its NAI in a FA-NAI extension in the UDP request. This ext >MUST be used if a AAA distributed FA-HA key is used. This will let the >HA key the SA on the FQDN of the FA instead of IP address. > That would prevent using aliases, so if anything you'd need to key it on the ip address that you get by resolving that particular FQDN. I am a bit confused about why you'd want to retain the FA-Host AVP while at the same time sending similar information at the MobileIP level? If the FA-Host AVP were to be retained it would most certainly have to be supplied by the FA itself and not taken from the Origin-Host avp of the AMR. But if what you will eventually need is an IP address why not send an IP address? Further investigation by Fredrik in the MobileIP RFC reveals that it is undefined which IP address to use when looking up SAs. It is defined for the SA between MN and HA, but *not* for FA and HA. It simply says that it must be an IP address. This is of course a source of interopability problems that needs to be dealt with. Our local Mobile IP guy exclaimed with surprise for instance "It's not the CoA?" j From owner-aaa-wg@merit.edu Thu Apr 4 03:21:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06827 for ; Thu, 4 Apr 2002 03:21:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E05C912B1; Thu, 4 Apr 2002 03:21:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAE24912B2; Thu, 4 Apr 2002 03:21:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57A64912B1 for ; Thu, 4 Apr 2002 03:21:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 345E05DE04; Thu, 4 Apr 2002 03:21:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 5A90A5DDB9 for ; Thu, 4 Apr 2002 03:21:19 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g348L8I09100; Thu, 4 Apr 2002 10:21:08 +0200 Message-ID: <3CAC0CCD.8020504@ipunplugged.com> Date: Thu, 04 Apr 2002 10:20:29 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: John Loughney , Tony Johansson , David Spence , aaa-wg Subject: Re: [AAA-WG]: [issue]: New generic host identification AVPs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As discussed in issue 305 of late there seems to be little if any use for anything except the IP address of the FA, so it at least seems reasonable to make the MIP-Foreign-Agent-Host avp contain an IPv4 address. This will become clearer in the next few days no doubt. j Bob Kopacz wrote: >Issue : New generic host identification AVPs >Submitter name: Bob Kopacz >Submitter email address:bkopacz@interlinknetworks.com >Date first submitted: 04-03-2002 >Reference: >Document: Base-10, Mobile-IPv4-10 >Comment type: Technical >Priority: 1 >Section: > >Rationale/Explanation of issue: > > In the Mobile IPv4 draft, there are various AVPs which carry the > identity, or identity+realm, of the various participants in a mobile > session. > > The current plus proposed AVPs are: > > - MIP-Home-Agent-Host ::= < Grouped AVP:... > > { Destination-Realm } > { Destination-Host } > * [ AVP ] > > - MIP-Home-Agent-Address AVP = IP address of HA > > - MIP-Originating-Foreign-AAA ::= < Grouped AVP:... > > { Origin-Realm } > { Origin-Host } > * [ AVP ] > > - MIP-Candidate-Home-Agent-Host = diameter identity of candidate HA > > - MIP-Foreign-Agent-Host = diameter identity of FA > > The existing set of identification AVPs has become muddled: Sometimes > the realm is part of the information, sometimes the realm is inferred > from other information. The IP address information is carried > separately from the identity. And the original meaning of the existing > Destination-xxx and Origin-xxx AVPs has been overloaded so that new AVPs > needn't be created. > > >Requested Change: > > 1. Create three generic AVPs, called "Host-Identity" and "Host-Realm" > and "Host-IPv4-Address", which are intended to be member AVPs of a > grouped AVP. > > Define these AVPs in the Base document, right after the 6.x sections > which define the Origin-xxx and Destination-xxx AVPs. The reason for > putting these in the Base document is so that they are made available > to other applications. > > "6.x Host-Identity AVP > > "The Host-Identity AVP (AVP Code TBD) is of type DiameterIdentity and > contains the identity of a Diameter agent. This AVP is intended to be > a member of a grouped AVP which carries a collection of Diameter > identification information for a Diameter node. > > "6.x Host-Realm AVP > > "The Host-Identity AVP (AVP Code TBD) is of type UTF8String and contains > the realm of a Diameter agent. This AVP is intended to be a member of > a grouped AVP which carries a collection of Diameter identification > information for a Diameter node. > > "6.x Host-IPv4-Address AVP > > "The Host-IPv4-Address AVP (AVP Code TBD) is of type IPAddress and > contains the IPv4 address of a Diameter agent. This AVP is intended to > be a member of a grouped AVP which carries a collection of Diameter > identification information for a Diameter node." > > > 2. In the Diameter Mobile IPv4 draft, redefine the > AVPs which carry the identification information for the > participants in the mobile session, as follows: > > MIP-Originating-Foreign-AAA ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Candidate-Home-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Foreign-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > > MIP-Home-Agent ::= < AVP Header:... > > { Host-Realm } > { Host-Identity } > [ Host-IPv4-Address ] > > From owner-aaa-wg@merit.edu Thu Apr 4 04:21:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07544 for ; Thu, 4 Apr 2002 04:21:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 727EA912B2; Thu, 4 Apr 2002 04:20:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 402DE912B3; Thu, 4 Apr 2002 04:20:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E54D2912B2 for ; Thu, 4 Apr 2002 04:20:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF7F15DE04; Thu, 4 Apr 2002 04:20:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id 14F415DDAB for ; Thu, 4 Apr 2002 04:20:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g349Kgs7005784; Thu, 4 Apr 2002 11:20:42 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g349KgUD010876; Thu, 4 Apr 2002 12:20:42 +0300 (EET DST) Message-ID: <3CAC1AEA.AD3184C3@lmf.ericsson.se> Date: Thu, 04 Apr 2002 12:20:42 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Elena.Lialiamou@nokia.com Cc: jari.arkko@kolumbus.fi, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <93532512B06FC3489824C18037DB3D4B7B75CD@esebe015.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The purpose should be to make proper data collection part of the diameter > accounting off-loading thus the actual billing process. Otherwise, if > diameter accounting does not offer proper data collection, needed sanity > checks etc then in terms of accounting protocol would not be offering > advantages over other accounting /collection mechanisms which do offer > some of the above. Shouldn't the purpose of diameter accounting be to > offer as reliable data collection as possible already within the > protocol layer? Otherwise, relaying on the billing process is something > that can be done without Diameter accounting. Well, certain functions need to be performed between a service and the bill from the service, but exactly where those happen is a design issue. As far as other protocols possibly offering some of these functions I can only repeat what I said earlier about reordering, reboots etc. These don't appear to be issues limited just to the Diameter protocol, they would apply to other solutions as well. To me, the tradeoffs are pretty clearly such that we should allow even reboot-damaged record streams to come in. But others may disagree and apparently you do. However, I'd like to point out that your product *can* ensure ordering if it wants to - there may be service providers that want to reduce the tasks of the billing post processing phase at the expense of losing some records. In conclusion, you get what you want and I also get what I want. However, if you want Diameter to *require* these checks then you'll get what you want but I can't get what I want. So... > How is the server supposed to process differently those three > different messages if their order does not make any sense? I get the feeling that we are entering a philosophical discussion. What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 in a record state or not? It is stored in a file or data base in the Diameter accounting server, so it should be considered state. Similarly for the Accounting-Record-Type AVP, right? All of this information is available for either immediate or later processing. The only question is if we will decline receiving records in order. > That should be stated in the doc so that "simple accounting" > does not require state but "state related" accounting > does require or in some better way ? Perhaps this is our way to a compromise. Why don't we state the situation about the potential immediate use or just storage of the records in the document. For instance: "Note that the server side state machines requires the reception of accounting records and does not place any standards requirement on the processing of these records. Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications." Jari From owner-aaa-wg@merit.edu Thu Apr 4 04:46:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08154 for ; Thu, 4 Apr 2002 04:46:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31FD9912B3; Thu, 4 Apr 2002 04:45:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3750912B4; Thu, 4 Apr 2002 04:45:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51845912B3 for ; Thu, 4 Apr 2002 04:45:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F3D15DE04; Thu, 4 Apr 2002 04:45:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 42E345DDAB for ; Thu, 4 Apr 2002 04:45:27 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g349jf522366 for ; Thu, 4 Apr 2002 12:45:41 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 12:45:26 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 12:45:24 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 12:45:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 12:45:24 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF27184212040@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbuhpTkfXyhmY4TF+sBo/+k/sX4gAAlIFg From: To: Cc: , , , X-OriginalArrivalTime: 04 Apr 2002 09:45:24.0459 (UTC) FILETIME=[719E5BB0:01C1DBBD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA08154 Hi, I may have missed some parts of the discussion so forgive me if my question is irrelevant.. If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? br, JPK -----Original Message----- From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] Sent: 04. April 2002 12:21 To: Lialiamou Elena (NET-IMN/Helsinki) Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server > The purpose should be to make proper data collection part of the diameter > accounting off-loading thus the actual billing process. Otherwise, if > diameter accounting does not offer proper data collection, needed sanity > checks etc then in terms of accounting protocol would not be offering > advantages over other accounting /collection mechanisms which do offer > some of the above. Shouldn't the purpose of diameter accounting be to > offer as reliable data collection as possible already within the > protocol layer? Otherwise, relaying on the billing process is something > that can be done without Diameter accounting. Well, certain functions need to be performed between a service and the bill from the service, but exactly where those happen is a design issue. As far as other protocols possibly offering some of these functions I can only repeat what I said earlier about reordering, reboots etc. These don't appear to be issues limited just to the Diameter protocol, they would apply to other solutions as well. To me, the tradeoffs are pretty clearly such that we should allow even reboot-damaged record streams to come in. But others may disagree and apparently you do. However, I'd like to point out that your product *can* ensure ordering if it wants to - there may be service providers that want to reduce the tasks of the billing post processing phase at the expense of losing some records. In conclusion, you get what you want and I also get what I want. However, if you want Diameter to *require* these checks then you'll get what you want but I can't get what I want. So... > How is the server supposed to process differently those three > different messages if their order does not make any sense? I get the feeling that we are entering a philosophical discussion. What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 in a record state or not? It is stored in a file or data base in the Diameter accounting server, so it should be considered state. Similarly for the Accounting-Record-Type AVP, right? All of this information is available for either immediate or later processing. The only question is if we will decline receiving records in order. > That should be stated in the doc so that "simple accounting" > does not require state but "state related" accounting > does require or in some better way ? Perhaps this is our way to a compromise. Why don't we state the situation about the potential immediate use or just storage of the records in the document. For instance: "Note that the server side state machines requires the reception of accounting records and does not place any standards requirement on the processing of these records. Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications." Jari From owner-aaa-wg@merit.edu Thu Apr 4 05:00:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08457 for ; Thu, 4 Apr 2002 05:00:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E8C8912B4; Thu, 4 Apr 2002 05:00:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6DE6912B5; Thu, 4 Apr 2002 05:00:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83D5C912B4 for ; Thu, 4 Apr 2002 05:00:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id D06245DDED; Thu, 4 Apr 2002 05:00:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 4F8115DDAB for ; Thu, 4 Apr 2002 05:00:01 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g349xwY14393; Thu, 4 Apr 2002 11:59:58 +0200 Message-ID: <3CAC23F6.9060505@ipunplugged.com> Date: Thu, 04 Apr 2002 11:59:18 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >>Added to to section 1.0: >> >>"1.0 Introduction >> >> ... >> >>Furthermore, the nature of mobile IP also means that the mobile node >>will do handoffs between different foreign agents and to guarantee >>that a registered user always ends up in the same initial AAAH the >>Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to >>assist the AAAH in routing the messages to a mobile node's home agent >>the mobile node MUST always include the HA NAI [AAANAI]. >> > >--> How about changing the tail of the first sentence to "the Mobile >Node, upon changing his point of attachment for a given session, MUST >include the home NAI and the AAAH NAI [AAANAI]". Just to make it clear >that the AAAH NAI information isn't required in the initial Registration >Request of a session. > >--> How about changing the second sentence to: "Finally, to assist the >AAAH in routing the messages to a mobile node's home agent the mobile >node MUST include the HA NAI [AAANAI], if including an HA IP address >other than 0.0.0.0 or 255.255.255.255" > >--> The plan, then, is that exactly one AAAH will be employed for the >life of a MN's session. And if that AAAH becomes unavailable, it is >"game over" for the MN's session, even if other AAAHs are available? If >this is true, should this be explicitly stated? > How about not breaking what was not previously broken instead? I will consider anything that requires that the same AAAH be used throughout the mobile node's session a showstopper bug. If you for some reason *prefer* that an MN use the same AAAH throughout the session then by all means introduce this redundant functionality as a MAY. >>Figure 2 shows the message flows involved when the foreign agent >>invokes the AAA infrastructure to request that a mobile node be >>authenticated and authorized. Note that it is not required that the >>foreign agent invoke AAA services every time a Registration Request >>is received from the mobile, but rather only when the prior >>authorization from the AAAH expires. >> > >The last sentence, beginning "Note that...", either needs more >clarification, or maybe should be striken. > Agreed. There should probably be something regarding Mobile IP tunnel renewal. >Also, for example, doesn't this sentence conflict with the last sentence >of the first paragraph of section 1.3, which says that "Therefore, it >MUST be assumed that a foreign agent is not aware that a registration >request from a mobile node has been previously authorized." > But section 1.3 is with regard to FA handover. If the FA has a session (Diameter or MobileIP for that matter) for a particular MN then obviously it knows that there was a previous authorization. The intent of section 1.3 is to explain why the AAAFs and AAAHs can't assume that there isn't already a session just because there is no Destination-Host in the AMR. >Also, wouldn't there be other reasons for the FA to invoke AAA services, >beyond "*only* when the prior authorization from the AAAH expires" >E.g, the authorization might not have expired, but maybe the new FA >needs an FA-xx key. Or the key lifetime is approaching expiration. > >--> I would suggest either striking the "Note that..." sentence altogether, or trimming it to "It is not required that the foreign agent >invoke AAA services every time a Registration Request is received from >the mobile". > First of all, I agree that there could be other reasons for the FA to invoke AAA services. Then again the sentence is more ambigous than in error really. It just states that the only time that the FA is required to invoke AAA services is when the previous authorization expires, which is true. Remember that the key lifetime *IS* the authorization lifetime while Authorization-Lifetime is used as the MobileIP tunnel renewal interval. See issue #306. >>The expiration time of the >>authorization is communicated through the Authorization-Lifetime AVP >>in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. >> ....which of course means that this sentence is wildly misleading. >> >>A mobile node, which has been previously authenticated andauthorized, >>MUST always include the assigned home agent in the HA-NAI >>and the authorizing Home AAA server in the AAAH-NAI in the >>registration request message [AAANAI] sent to the FA, every time the >>Mobile Node needs to re-authenticating. So, in the event that the AMR >>generated by the FA is for a session that has was previously >>authorized, it MUST include the Destination-Host AVP, with the >>identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- >>Host AVP the identity of the assigned HA found in the HA-NAI. >> > >--> Replace the above paragraph (due to various typos) with: > > "A mobile node, which has been previously authenticated and authorized, > MUST always include the assigned home agent in the HA Identity subtype > of the AAA NAI extension, and the authorizing Home AAA server in the > AAAH Identity subtype of the AAA NAI extension, in the registration > request message [AAANAI] which is sent to the FA every time the Mobile > Node needs to re-authenticate. So, in the event that the AMR generated > by the FA is for a session that was previously authorized, it MUST > include the Destination-Host AVP, with the identity of the AAAH found in > the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and > realm of the assigned HA found in the HA-NAI." > I don't understand why you have chosen to make this fundamental restriction in the protocol? The only think that must remain constant during a session is the home agent and the HA-NAI part is then of course needed to make the protocol work, but why introduce the AAAH NAI just to make the protocol less capable? >--> How about appending the following sentence to the above paragraph: > > "Furthermore, if the Registration Request contains an AAAH-NAI, > then the FA sets the AMR's Destination-Realm based on the AAAH's NAI. > Otherwise the FA sets the AMR's Destination-Realm based on the MN's > NAI. > If the MN NAI works why use something else? Why not simply state that the MN's NAI MUST be used to deduce the realm? >--> And how about adding the following paragraph: > > "Whenever the mobile node specifies a home agent IP address with a value > other than 0.0.0.0 or 255.255.255.255 in a Registration Request, the > mobile node MUST also include an HA-NAI which conveys the home agent's > identity and realm." > >The above paragraph makes it clear that, if the MN knows who his HA is, >whether generating an initial Reg Req or a handoff Reg Req, the MN must >also specify the HA's identity. > Seems reasonable to me. >>If the mobile node was successfully authenticated, the AAAH checks if >>the Home Agent was located in the foreign realm, by checking the MIP- >>Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the >>Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. >> > >--> Exactly what is the check that the AAAH does with the values of the >MIP-Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP, and the >Home-Agent-In-Foreign-Network flag? I think too many AVPs are probably being >inspected here. Isn't the Home-Agent-In-Foreign-Network flag alone >sufficient to make the "HA is in foreign network" determination? > >--> Do we need the Home-Agent-In-Foreign-Network flag anymore? It seems >to be at best redundant, and at worst conflicting. Here's what I mean: > >As I understand it, the Home-Agent-In-Foreign-Network flag would be set >by an AAAF if and only if: >(a) the FA's AMR contained a MIP-HA-Host AVP, and >(b) the HA's realm (from the MIP-HA-Host AVP) is different from the >MN's home realm (from the AMR's Destination-Realm AVP). > >But the AAAH, when processing an AMR which contains a MIP-HA-Host AVP, >could just as easily check the HA's realm against his own, as to inspect >the Home-Agent-In-Foreign-Network flag (and the other two AVPs mentioned >above). And wouldn't have to worry about conflicting information. > I certainly don't understand why it would need to inspect the MIP-Originating-Foreign-AAA AVP. The Home-Agent-In-Foreign-Network flag might need to be retained to make this visible in the accounting which contains the feature vector, but the AAAH doesn't seem to need it to determine if the HA is in the foreign realm or not. From Tony's answer: >checking this flag alone does not provide the capability of determining that >there may be more than one foreign network involved. > While this is true, it makes me wonder what we do differently if more than one foreign network *is* involved. The only place it seems to make a difference to me is in the accounting and billing and it's not obvious to me that it can be determined (easily) from the accounting messages. Potentially, the session ids could be used I guess, but it seems laborious. If the server is stateless or the request is handled by a different AAAH, wouldn't additional information be needed beyond those avps mentioned be needed to detect a handover between different foreign networks anyway? >>A mobile node's session is identified via its identity in the User- >>Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address >>AVPs. This is necessary in order to allow the session state machine, >>defined in the base protocol [DIAMBASE], to be used unmodified with >>this application. >> I don't like this paragraph for many reasons. For one there has been many many changes to the statemachine after it was written and I guess someone should check if it is still true. Another is that it is virtually impossible to implement the Diameter Mobile IP application sessions with an "unmodified" base session state machine. >--> I also like the idea of the the originating AAAF *always* including >his identity in an AMR, whether including a Candidate-MIP-HA or not. >This has two virtues: > >1. The AAAH and HA always have a fixed place to look for the FA's >identity. > I suppose you mean the AAAF's identity? >2. The AAAH can be assured that the AMR has actually passed through an >AAAF on the way, and thus that the foreign network had its opportunity >to apply its policy. What I mean is this: When the FA sends an AMR, it >is routed by Destination-Realm. Suppose the FA has a Relay between >itself and the local AAAF. The FA sends the AMR to the Relay. If the >Relay's routing is misconfigured, the Relay may just route the AMR >directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary >know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA >AVP was required but not present, this would tip off the AAAH that >something was amiss. > If we agree to say that a AAAF must add it's identity upon processing a message then I have no objections. But if you are saying that a network MUST have a AAAF I disagree. Consequently the AAAH can't know if something is amiss or not. >--> This is a good place to add a paragraph that defines the exact test >that the AAAF does to make the "HA-is-in-Foreign-Network" determination. > To which Tony answered: >The protocol provides all the necessary info. It's an implementation specific >detail as to how this exact test is performed. > 1. How can you be so sure about that until you have a "peer-reviewed" algorithm for it? 2. Since the network topology of the home network comes into play here, how does the AAAF implementation know how to perform the test? Let's say elvis@earthling.space.com visits the alien department and gets an HA in the alien.space.com realm, which is foreign to elvis even if only slightly. Next he goes outside and switches to the wlan.isp.com realm. Please explain how aaaf.wlan.isp.com knows that the HA is in a foreign realm. We don't have to put the algorithm in the draft, but I would like to see one that works. >>AAAH SHOULD send the HAR to the originating AAAF by including the >>Destination-Host AVP set to the value found in the AMR's MIP- >>Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or >>the MIP-Candidate-Home-Agent-Host AVP found in the AMR. >> > >Probably my fault, but I'm confused. > >1. It looks like sometimes the HAR is sent with a Destination-Host set >to the HA's identity, and other times with the Destination-Host set to >an AAAF's identity. > I'm curious about the SHOULD. What should it do otherwise? Is the above a recommendation to send it to the AAAF but it's ok to send it to the HA too? Or MUST it always send it to the AAAF (if the HA is in the foreign net) but it may potentially use other sources of information to deduce it's identity? j From owner-aaa-wg@merit.edu Thu Apr 4 05:06:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08633 for ; Thu, 4 Apr 2002 05:06:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3ED7912B5; Thu, 4 Apr 2002 05:06:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77990912B6; Thu, 4 Apr 2002 05:06:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24A0A912B5 for ; Thu, 4 Apr 2002 05:06:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 034C05DDAA; Thu, 4 Apr 2002 05:06:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 2B9A55DD9B for ; Thu, 4 Apr 2002 05:06:32 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g34A6UA15260; Thu, 4 Apr 2002 12:06:30 +0200 Message-ID: <3CAC257E.8090201@ipunplugged.com> Date: Thu, 04 Apr 2002 12:05:50 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: Jari.Arkko@lmf.ericsson.se, jari.arkko@kolumbus.fi, aaa-wg@merit.edu, Elena.Lialiamou@nokia.com Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <0AA9E01B31168E42A308714A6EF27184212040@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Well, I'm not sure there are that many possible actions you *can* take. Any such action would have to take place through the authorization session which is the only one with the power to initiate a session termination. The communication between the accounting session and the authorization session, which may not reside on the same machine, is not specified by the protocol and probably wisely so. j juha-pekka.koskinen@nokia.com wrote: >Hi, > >I may have missed some parts of the discussion so forgive me if my question is irrelevant.. > >If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? > >br, >JPK > >-----Original Message----- >From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] >Sent: 04. April 2002 12:21 >To: Lialiamou Elena (NET-IMN/Helsinki) >Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State >Machines into Client vs. Server > > > >>The purpose should be to make proper data collection part of the diameter >>accounting off-loading thus the actual billing process. Otherwise, if >>diameter accounting does not offer proper data collection, needed sanity >>checks etc then in terms of accounting protocol would not be offering >>advantages over other accounting /collection mechanisms which do offer >>some of the above. Shouldn't the purpose of diameter accounting be to >>offer as reliable data collection as possible already within the >>protocol layer? Otherwise, relaying on the billing process is something >>that can be done without Diameter accounting. >> > >Well, certain functions need to be performed between a service >and the bill from the service, but exactly where those happen >is a design issue. As far as other protocols possibly offering >some of these functions I can only repeat what I said earlier >about reordering, reboots etc. These don't appear to be issues >limited just to the Diameter protocol, they would apply to >other solutions as well. To me, the tradeoffs are pretty clearly >such that we should allow even reboot-damaged record streams >to come in. But others may disagree and apparently you do. >However, I'd like to point out that your product *can* ensure >ordering if it wants to - there may be service providers >that want to reduce the tasks of the billing post processing >phase at the expense of losing some records. > >In conclusion, you get what you want and I also get what I want. >However, if you want Diameter to *require* these checks then >you'll get what you want but I can't get what I want. So... > >>How is the server supposed to process differently those three >>different messages if their order does not make any sense? >> > >I get the feeling that we are entering a philosophical discussion. >What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 >in a record state or not? It is stored in a file or data base >in the Diameter accounting server, so it should be considered >state. Similarly for the Accounting-Record-Type AVP, right? >All of this information is available for either immediate or >later processing. > >The only question is if we will decline receiving records in >order. > >>That should be stated in the doc so that "simple accounting" >>does not require state but "state related" accounting >>does require or in some better way ? >> > >Perhaps this is our way to a compromise. Why don't we state >the situation about the potential immediate use or just >storage of the records in the document. For instance: > >"Note that the server side state machines requires the >reception of accounting records and does not place any >standards requirement on the processing of these records. >Implementations of Diameter MAY perform checking, ordering, >correlation, fraud detection, and other tasks based on these records. >Both base Diameter AVPs as well as application specific >AVPs MAY be inspected as a part of these tasks. >The tasks can happen either immediately after record >reception or in a post-processing phase. However, as these >tasks are typically application or even policy dependent, >they are not standardized by the Diameter specifications." > >Jari > From owner-aaa-wg@merit.edu Thu Apr 4 05:14:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08732 for ; Thu, 4 Apr 2002 05:14:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 691A7912B6; Thu, 4 Apr 2002 05:14:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32A30912B7; Thu, 4 Apr 2002 05:14:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0837B912B6 for ; Thu, 4 Apr 2002 05:14:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id E34E75DDAA; Thu, 4 Apr 2002 05:14:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 6FCF05DD9B for ; Thu, 4 Apr 2002 05:14:18 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g34AEH3G013757; Thu, 4 Apr 2002 12:14:17 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g34AEGUD014793; Thu, 4 Apr 2002 13:14:16 +0300 (EET DST) Message-ID: <3CAC2778.D9E5A4B@lmf.ericsson.se> Date: Thu, 04 Apr 2002 13:14:16 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: jari.arkko@kolumbus.fi, johanj@ipunplugged.com, aaa-wg@merit.edu, Elena.Lialiamou@nokia.com Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <0AA9E01B31168E42A308714A6EF27184212040@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit juha-pekka.koskinen@nokia.com wrote: > > Hi, > > I may have missed some parts of the discussion so forgive me if my question is irrelevant.. Not at all. Your comments are very relevant. > If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? I sympathize with the desire to do that but the question is, what *can* we do? Answer A: Nothing. (current state machine) Answer B: Close the session. But what if there was a network partition and the records come in tomorrow when it is fixed? Jari From owner-aaa-wg@merit.edu Thu Apr 4 06:18:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09716 for ; Thu, 4 Apr 2002 06:18:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DEB5912B9; Thu, 4 Apr 2002 06:18:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FB1D912BB; Thu, 4 Apr 2002 06:18:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC66F912B9 for ; Thu, 4 Apr 2002 06:18:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 851805DD9B; Thu, 4 Apr 2002 06:18:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C4D775DD94 for ; Thu, 4 Apr 2002 06:18:30 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34BIh504636 for ; Thu, 4 Apr 2002 14:18:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 14:18:26 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 14:16:55 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 14:16:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 14:16:54 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF27184212042@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbwX8ypgToPrTBQueX4qfUiztNGgABNrNw From: To: Cc: , , , X-OriginalArrivalTime: 04 Apr 2002 11:16:55.0109 (UTC) FILETIME=[3A4D0F50:01C1DBCA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA09716 Hi, The case I referred is that the connection is ok but the client just failed to start the timer. In these cases the server (when case noticed) may send ASR and client have to disconnect the session. When ASA is received, the server could also close the session. If ASA is not received, server will know that something more serious is wrong and left the session open(/pending). Then, I guess, there should not be problem when records come later? br, JPK -----Original Message----- From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] juha-pekka.koskinen@nokia.com wrote: > > Hi, > > I may have missed some parts of the discussion so forgive me if my question is irrelevant.. Not at all. Your comments are very relevant. > If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? I sympathize with the desire to do that but the question is, what *can* we do? Answer A: Nothing. (current state machine) Answer B: Close the session. But what if there was a network partition and the records come in tomorrow when it is fixed? Jari From owner-aaa-wg@merit.edu Thu Apr 4 06:40:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10128 for ; Thu, 4 Apr 2002 06:40:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 441E1912BB; Thu, 4 Apr 2002 06:40:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15D59912BC; Thu, 4 Apr 2002 06:40:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C725E912BB for ; Thu, 4 Apr 2002 06:40:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABB965DDA7; Thu, 4 Apr 2002 06:40:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 0DECD5DD94 for ; Thu, 4 Apr 2002 06:40:06 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g34Be3e14451; Thu, 4 Apr 2002 13:40:03 +0200 Message-ID: <3CAC3B6B.9050502@ipunplugged.com> Date: Thu, 04 Apr 2002 13:39:23 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: Jari.Arkko@lmf.ericsson.se, jari.arkko@kolumbus.fi, aaa-wg@merit.edu, Elena.Lialiamou@nokia.com Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <0AA9E01B31168E42A308714A6EF27184212042@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit An accounting server can not initiate a session termination unless it through some means has access to the session id of the authorization session. j juha-pekka.koskinen@nokia.com wrote: >Hi, > >The case I referred is that the connection is ok but the client just failed to start the timer. > >In these cases the server (when case noticed) may send ASR and client have to disconnect the session. >When ASA is received, the server could also close the session. >If ASA is not received, server will know that something more serious is wrong and left the session open(/pending). Then, I guess, there should not be problem when records come later? > >br, >JPK > > >-----Original Message----- >From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > > >juha-pekka.koskinen@nokia.com wrote: > >>Hi, >> >>I may have missed some parts of the discussion so forgive me if my question is irrelevant.. >> > >Not at all. Your comments are very relevant. > >>If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? >> > >I sympathize with the desire to do that but the question is, >what *can* we do? > >Answer A: Nothing. (current state machine) > >Answer B: Close the session. But what if there was a network >partition and the records come in tomorrow when it is fixed? > >Jari > From owner-aaa-wg@merit.edu Thu Apr 4 06:59:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10326 for ; Thu, 4 Apr 2002 06:59:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6481E912BD; Thu, 4 Apr 2002 06:59:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38416912BE; Thu, 4 Apr 2002 06:59:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A89A5912BD for ; Thu, 4 Apr 2002 06:59:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7EA395DDED; Thu, 4 Apr 2002 06:59:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 9F17A5DD94 for ; Thu, 4 Apr 2002 06:59:09 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34BxN505392 for ; Thu, 4 Apr 2002 14:59:23 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 14:59:08 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 14:59:08 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 14:59:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 14:59:07 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF27184212044@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbzXYyKx/BO8HGSiaZpwkAzmYE5wAAWhSg From: To: Cc: , , , X-OriginalArrivalTime: 04 Apr 2002 11:59:07.0930 (UTC) FILETIME=[1FFADFA0:01C1DBD0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10326 Hi, But should the accounting server be able to terminate the accounting session (and client will do the rest)? The base chapter 8.5 refers :"...the diameter server that originally _authorized_ the session may be required to cause that session to be stopped for _credit_ or other reasons..." The credit is mentioned as a one termination reason, so should also the accounting server be able to do that termination with ASR?? Is there something missing or too much? ;) br, JPK -----Original Message----- From: ext Johan Johansson [mailto:johanj@ipunplugged.com] Sent: 04. April 2002 14:39 To: Koskinen Juha-Pekka (NET/Tampere) Cc: Jari.Arkko@lmf.ericsson.se; jari.arkko@kolumbus.fi; aaa-wg@merit.edu; Lialiamou Elena (NET-IMN/Helsinki) Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server An accounting server can not initiate a session termination unless it through some means has access to the session id of the authorization session. j juha-pekka.koskinen@nokia.com wrote: >Hi, > >The case I referred is that the connection is ok but the client just failed to start the timer. > >In these cases the server (when case noticed) may send ASR and client have to disconnect the session. >When ASA is received, the server could also close the session. >If ASA is not received, server will know that something more serious is wrong and left the session open(/pending). Then, I guess, there should not be problem when records come later? > >br, >JPK > > >-----Original Message----- >From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > > >juha-pekka.koskinen@nokia.com wrote: > >>Hi, >> >>I may have missed some parts of the discussion so forgive me if my question is irrelevant.. >> > >Not at all. Your comments are very relevant. > >>If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...? >> > >I sympathize with the desire to do that but the question is, >what *can* we do? > >Answer A: Nothing. (current state machine) > >Answer B: Close the session. But what if there was a network >partition and the records come in tomorrow when it is fixed? > >Jari > From owner-aaa-wg@merit.edu Thu Apr 4 07:46:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11897 for ; Thu, 4 Apr 2002 07:46:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37496912C3; Thu, 4 Apr 2002 07:45:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04B0D912C4; Thu, 4 Apr 2002 07:45:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B63EB912C3 for ; Thu, 4 Apr 2002 07:45:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 911705DDF7; Thu, 4 Apr 2002 07:45:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 30F025DDED for ; Thu, 4 Apr 2002 07:45:40 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ACDA26A907; Thu, 4 Apr 2002 15:45:39 +0300 (EEST) Message-ID: <3CAC3D48.60302@kolumbus.fi> Date: Thu, 04 Apr 2002 14:47:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: Jari.Arkko@lmf.ericsson.se, johanj@ipunplugged.com, aaa-wg@merit.edu, Elena.Lialiamou@nokia.com Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <0AA9E01B31168E42A308714A6EF27184212042@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit juha-pekka.koskinen@nokia.com wrote: > Hi, > > The case I referred is that the connection is ok but the client just failed to start the timer. > > In these cases the server (when case noticed) may send ASR and client have to disconnect the session. That's fine but what mechanisms do we have for knowing if the client failed to start the timer, or if this is a network problem? Note that we already have Accounting-Realtime-Requirements AVP which, on correctly implemented Diameter nodes, allows the server to control what to do if acct data doesn't get through. But I don't see any way how I could distinguish incorrect implementation and network partition just by looking at the messages the server receives. Do you? Jari From owner-aaa-wg@merit.edu Thu Apr 4 07:48:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11955 for ; Thu, 4 Apr 2002 07:48:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D729912C4; Thu, 4 Apr 2002 07:48:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E11B9912C5; Thu, 4 Apr 2002 07:48:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48605912C4 for ; Thu, 4 Apr 2002 07:48:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20F725DE24; Thu, 4 Apr 2002 07:48:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D37E15DDED for ; Thu, 4 Apr 2002 07:48:01 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C92F56A907; Thu, 4 Apr 2002 15:48:00 +0300 (EEST) Message-ID: <3CAC3DD5.5040500@kolumbus.fi> Date: Thu, 04 Apr 2002 14:49:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: johanj@ipunplugged.com, Jari.Arkko@lmf.ericsson.se, aaa-wg@merit.edu, Elena.Lialiamou@nokia.com Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <0AA9E01B31168E42A308714A6EF27184212044@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit juha-pekka.koskinen@nokia.com wrote: > Hi, > > But should the accounting server be able to terminate the accounting session (and client will do the rest)? > > The base chapter 8.5 refers :"...the diameter server that originally _authorized_ the session may be required to cause that session to be stopped for _credit_ or other reasons..." > > The credit is mentioned as a one termination reason, so should also the accounting server be able to do that termination with ASR?? Is there something missing or too much? ;) I believe the idea is that ASR can be used, on a application dependent basis, at the server end to cause a disconnect. Accounting-Auth server communication may be needed to accomplish this in some cases. But in all cases the reasons to do an ASR are outside the scope of the Diameter state machines. Jari From owner-aaa-wg@merit.edu Thu Apr 4 07:58:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12324 for ; Thu, 4 Apr 2002 07:58:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A216E912C6; Thu, 4 Apr 2002 07:58:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 068FC912C7; Thu, 4 Apr 2002 07:58:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64D09912C6 for ; Thu, 4 Apr 2002 07:58:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B6465DE24; Thu, 4 Apr 2002 07:58:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 8E6345DDED for ; Thu, 4 Apr 2002 07:58:24 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34Cwc523685 for ; Thu, 4 Apr 2002 15:58:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 15:58:23 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 15:58:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 15:58:22 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E41BA@esebe016.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHbuhUNVDTQHExHTiG3o+xlz7tnBgAEzASg From: To: , Cc: , , X-OriginalArrivalTime: 04 Apr 2002 12:58:23.0244 (UTC) FILETIME=[671CBCC0:01C1DBD8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA12324 Hi Jari, I beleive it is not question of philosophical discussion at all, if we have an accounting session the state machine must be open. Idle means that we don't have any ongoing accounting session. It is definitely question of convention, clarity and also practicality. I agree with your text, and this has to be written in the spec.: "Note that the server side state machines requires the reception of accounting records and does not place any standards requirement on the processing of these records. Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications." And I'm fine with the original Pete proposal for the accounting session state for the Server with minor addition, I still insist that the state must be Open when an accounting session is ongoing: SERVER, ACCOUNTING State Event Action New State ---------------------------------------------------------------------- Idle Accounting start request send Open received, and successfully accounting processed. start answer Idle Accounting event request send Idle received, and successfully accounting processed. event answer Idle Accounting request received send Idle (Interim Record or Start req.) answer no space left to store records Result-code= out-of-space Idle Interim Record received send Open and successfully processed accounting answer Open Interim Record received send Open and successfully processed accounting answer Open Accounting stop request send Idle received, and successfully accounting processed stop answer Open Accounting request received send Idle (Interim Record or Stop req.) answer no space left to store records Result-code= out-of-space A little explanation of the addition I have done to the original Pete proposal. When there is no space left to store the record and the accounting session is Open the new state will be idle. If accounting request was "Interim", the client may not close the session when it receives the answer with Result-code=out-of-space (depending on the realtime AVP and client's buffer status) thus the client can still send subsequent interim record. If the error condition is still active in the server when subsequent interim records are received the state will stay idle otherwise the session is open again. In general the possibility to receive interim record in idle state is also useful when the client need to send these records to an alternate peer (server) in case of accounting server failure. I hope everybody is happy with this simple state model that clearly show, without ambiguity, when the accounting session is open and when is not. BR Marco > -----Original Message----- > From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > Sent: 04. April 2002 12:21 > To: Lialiamou Elena (NET-IMN/Helsinki) > Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > > > The purpose should be to make proper data collection part > of the diameter > > accounting off-loading thus the actual billing process. > Otherwise, if > > diameter accounting does not offer proper data collection, > needed sanity > > checks etc then in terms of accounting protocol would not > be offering > > advantages over other accounting /collection mechanisms > which do offer > > some of the above. Shouldn't the purpose of diameter > accounting be to > > offer as reliable data collection as possible already within the > > protocol layer? Otherwise, relaying on the billing process > is something > > that can be done without Diameter accounting. > > Well, certain functions need to be performed between a service > and the bill from the service, but exactly where those happen > is a design issue. As far as other protocols possibly offering > some of these functions I can only repeat what I said earlier > about reordering, reboots etc. These don't appear to be issues > limited just to the Diameter protocol, they would apply to > other solutions as well. To me, the tradeoffs are pretty clearly > such that we should allow even reboot-damaged record streams > to come in. But others may disagree and apparently you do. > However, I'd like to point out that your product *can* ensure > ordering if it wants to - there may be service providers > that want to reduce the tasks of the billing post processing > phase at the expense of losing some records. > > In conclusion, you get what you want and I also get what I want. > However, if you want Diameter to *require* these checks then > you'll get what you want but I can't get what I want. So... > > > How is the server supposed to process differently those three > > different messages if their order does not make any sense? > > I get the feeling that we are entering a philosophical discussion. > What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 > in a record state or not? It is stored in a file or data base > in the Diameter accounting server, so it should be considered > state. Similarly for the Accounting-Record-Type AVP, right? > All of this information is available for either immediate or > later processing. > > The only question is if we will decline receiving records in > order. > > > That should be stated in the doc so that "simple accounting" > > does not require state but "state related" accounting > > does require or in some better way ? > > Perhaps this is our way to a compromise. Why don't we state > the situation about the potential immediate use or just > storage of the records in the document. For instance: > > "Note that the server side state machines requires the > reception of accounting records and does not place any > standards requirement on the processing of these records. > Implementations of Diameter MAY perform checking, ordering, > correlation, fraud detection, and other tasks based on these records. > Both base Diameter AVPs as well as application specific > AVPs MAY be inspected as a part of these tasks. > The tasks can happen either immediately after record > reception or in a post-processing phase. However, as these > tasks are typically application or even policy dependent, > they are not standardized by the Diameter specifications." > > Jari > From owner-aaa-wg@merit.edu Thu Apr 4 08:04:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12503 for ; Thu, 4 Apr 2002 08:04:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6803C912C7; Thu, 4 Apr 2002 08:03:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 315B5912C8; Thu, 4 Apr 2002 08:03:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0A87912C7 for ; Thu, 4 Apr 2002 08:03:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id B401B5DDB3; Thu, 4 Apr 2002 08:03:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id D54B15DDA2 for ; Thu, 4 Apr 2002 08:03:54 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g34D3r807232; Thu, 4 Apr 2002 15:03:53 +0200 Message-ID: <3CAC4F0F.7000007@ipunplugged.com> Date: Thu, 04 Apr 2002 15:03:11 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: marco.stura@nokia.com Cc: Jari.Arkko@lmf.ericsson.se, Elena.Lialiamou@nokia.com, jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <142DC466081D9B409AAD1DDCA4B21E1D9E41BA@esebe016.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit And what if no stop record is ever received? How does the server know that it can get rid of the session? j marco.stura@nokia.com wrote: >Hi Jari, > >I beleive it is not question of philosophical discussion at all, if we have an accounting >session the state machine must be open. Idle means that we don't have any ongoing >accounting session. It is definitely question of convention, clarity and also >practicality. >I agree with your text, and this has to be written in the spec.: > >"Note that the server side state machines requires the >reception of accounting records and does not place any >standards requirement on the processing of these records. >Implementations of Diameter MAY perform checking, ordering, >correlation, fraud detection, and other tasks based on these records. >Both base Diameter AVPs as well as application specific >AVPs MAY be inspected as a part of these tasks. >The tasks can happen either immediately after record >reception or in a post-processing phase. However, as these >tasks are typically application or even policy dependent, >they are not standardized by the Diameter specifications." > >And I'm fine with the original Pete proposal for the accounting session >state for the Server with minor addition, I still insist that the state >must be Open when an accounting session is ongoing: > > SERVER, ACCOUNTING > State Event Action New State > ---------------------------------------------------------------------- > > Idle Accounting start request send Open > received, and successfully accounting > processed. start > answer > > Idle Accounting event request send Idle > received, and successfully accounting > processed. event > answer > > Idle Accounting request received send Idle > (Interim Record or Start req.) answer > no space left to store records Result-code= > out-of-space > > Idle Interim Record received send Open > and successfully processed accounting > answer > > > Open Interim Record received send Open > and successfully processed accounting > answer > > Open Accounting stop request send Idle > received, and successfully accounting > processed stop answer > > Open Accounting request received send Idle > (Interim Record or Stop req.) answer > no space left to store records Result-code= > out-of-space > > > >A little explanation of the addition I have done to the original Pete proposal. >When there is no space left to store the record and the accounting session is >Open the new state will be idle. If accounting request was "Interim", the client >may not close the session when it receives the answer with Result-code=out-of-space >(depending on the realtime AVP and client's buffer status) thus the client >can still send subsequent interim record. >If the error condition is still active in the server when subsequent interim records >are received the state will stay idle otherwise the session is open again. > >In general the possibility to receive interim record in idle state is also useful >when the client need to send these records to an alternate peer (server) in case >of accounting server failure. > >I hope everybody is happy with this simple state model that clearly show, without >ambiguity, when the accounting session is open and when is not. > >BR >Marco > >>-----Original Message----- >>From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] >>Sent: 04. April 2002 12:21 >>To: Lialiamou Elena (NET-IMN/Helsinki) >>Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State >>Machines into Client vs. Server >> >> >> >>>The purpose should be to make proper data collection part >>> >>of the diameter >> >>>accounting off-loading thus the actual billing process. >>> >>Otherwise, if >> >>>diameter accounting does not offer proper data collection, >>> >>needed sanity >> >>>checks etc then in terms of accounting protocol would not >>> >>be offering >> >>>advantages over other accounting /collection mechanisms >>> >>which do offer >> >>>some of the above. Shouldn't the purpose of diameter >>> >>accounting be to >> >>>offer as reliable data collection as possible already within the >>>protocol layer? Otherwise, relaying on the billing process >>> >>is something >> >>>that can be done without Diameter accounting. >>> >>Well, certain functions need to be performed between a service >>and the bill from the service, but exactly where those happen >>is a design issue. As far as other protocols possibly offering >>some of these functions I can only repeat what I said earlier >>about reordering, reboots etc. These don't appear to be issues >>limited just to the Diameter protocol, they would apply to >>other solutions as well. To me, the tradeoffs are pretty clearly >>such that we should allow even reboot-damaged record streams >>to come in. But others may disagree and apparently you do. >>However, I'd like to point out that your product *can* ensure >>ordering if it wants to - there may be service providers >>that want to reduce the tasks of the billing post processing >>phase at the expense of losing some records. >> >>In conclusion, you get what you want and I also get what I want. >>However, if you want Diameter to *require* these checks then >>you'll get what you want but I can't get what I want. So... >> >>>How is the server supposed to process differently those three >>>different messages if their order does not make any sense? >>> >>I get the feeling that we are entering a philosophical discussion. >>What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 >>in a record state or not? It is stored in a file or data base >>in the Diameter accounting server, so it should be considered >>state. Similarly for the Accounting-Record-Type AVP, right? >>All of this information is available for either immediate or >>later processing. >> >>The only question is if we will decline receiving records in >>order. >> >>>That should be stated in the doc so that "simple accounting" >>>does not require state but "state related" accounting >>>does require or in some better way ? >>> >>Perhaps this is our way to a compromise. Why don't we state >>the situation about the potential immediate use or just >>storage of the records in the document. For instance: >> >>"Note that the server side state machines requires the >>reception of accounting records and does not place any >>standards requirement on the processing of these records. >>Implementations of Diameter MAY perform checking, ordering, >>correlation, fraud detection, and other tasks based on these records. >>Both base Diameter AVPs as well as application specific >>AVPs MAY be inspected as a part of these tasks. >>The tasks can happen either immediately after record >>reception or in a post-processing phase. However, as these >>tasks are typically application or even policy dependent, >>they are not standardized by the Diameter specifications." >> >>Jari >> > From owner-aaa-wg@merit.edu Thu Apr 4 08:33:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13561 for ; Thu, 4 Apr 2002 08:33:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F38AF912C8; Thu, 4 Apr 2002 08:33:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAEA0912C9; Thu, 4 Apr 2002 08:33:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 314B0912C8 for ; Thu, 4 Apr 2002 08:33:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C9735DDED; Thu, 4 Apr 2002 08:33:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 517135DDB4 for ; Thu, 4 Apr 2002 08:33:38 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34DXq521883 for ; Thu, 4 Apr 2002 16:33:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 16:33:35 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 16:33:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 16:33:36 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E41BB@esebe016.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHb2SyjhDmzsi/KRYunKR/DpCk96gAAdWBQ From: To: Cc: , , , X-OriginalArrivalTime: 04 Apr 2002 13:33:36.0855 (UTC) FILETIME=[52EC2E70:01C1DBDD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13561 what are the cases when stop record is not received? I would say: 1- network failure 2- Client error (e.g. spontaneous restart of the client, Diameter process failure...) A network failure should be detected at the transport layer. In general the accounting session will be closed if the transport layer detect a connection failure (it is an implementation issue how transport layer will instruct the Diameter layer). In case of client error sooner or later the transport layer connection will be closed and we go back to the previous case. If the message is lost due to temporary network overload/failure Diameter is running on reliable transport then the message will be re-transmitted at transport layer. In case of software bug in the client the problem is not in the server state model. Are these examples enough or you need more examples? BR Marco > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 04. April 2002 16:03 > To: Stura Marco (NET/Helsinki) > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > jari.arkko@kolumbus.fi; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > And what if no stop record is ever received? How does the server know > that it can get rid of the session? > > j > > marco.stura@nokia.com wrote: > > >Hi Jari, > > > >I beleive it is not question of philosophical discussion at > all, if we have an accounting > >session the state machine must be open. Idle means that we > don't have any ongoing > >accounting session. It is definitely question of convention, > clarity and also > >practicality. > >I agree with your text, and this has to be written in the spec.: > > > >"Note that the server side state machines requires the > >reception of accounting records and does not place any > >standards requirement on the processing of these records. > >Implementations of Diameter MAY perform checking, ordering, > >correlation, fraud detection, and other tasks based on these records. > >Both base Diameter AVPs as well as application specific > >AVPs MAY be inspected as a part of these tasks. > >The tasks can happen either immediately after record > >reception or in a post-processing phase. However, as these > >tasks are typically application or even policy dependent, > >they are not standardized by the Diameter specifications." > > > >And I'm fine with the original Pete proposal for the > accounting session > >state for the Server with minor addition, I still insist > that the state > >must be Open when an accounting session is ongoing: > > > > SERVER, ACCOUNTING > > State Event Action > New State > > > ---------------------------------------------------------------------- > > > > Idle Accounting start request send Open > > received, and successfully accounting > > processed. start > > answer > > > > Idle Accounting event request send Idle > > received, and successfully accounting > > processed. event > > answer > > > > Idle Accounting request received send Idle > > (Interim Record or Start req.) answer > > no space left to store records Result-code= > > out-of-space > > > > Idle Interim Record received send > Open > > and successfully processed accounting > > answer > > > > > > Open Interim Record received send Open > > and successfully processed accounting > > answer > > > > Open Accounting stop request send Idle > > received, and successfully accounting > > processed stop answer > > > > Open Accounting request received send > Idle > > (Interim Record or Stop req.) answer > > no space left to store records Result-code= > > out-of-space > > > > > > > >A little explanation of the addition I have done to the > original Pete proposal. > >When there is no space left to store the record and the > accounting session is > >Open the new state will be idle. If accounting request was > "Interim", the client > >may not close the session when it receives the answer with > Result-code=out-of-space > >(depending on the realtime AVP and client's buffer status) > thus the client > >can still send subsequent interim record. > >If the error condition is still active in the server when > subsequent interim records > >are received the state will stay idle otherwise the session > is open again. > > > >In general the possibility to receive interim record in idle > state is also useful > >when the client need to send these records to an alternate > peer (server) in case > >of accounting server failure. > > > >I hope everybody is happy with this simple state model that > clearly show, without > >ambiguity, when the accounting session is open and when is not. > > > >BR > >Marco > > > >>-----Original Message----- > >>From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > >>Sent: 04. April 2002 12:21 > >>To: Lialiamou Elena (NET-IMN/Helsinki) > >>Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu > >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + > Split State > >>Machines into Client vs. Server > >> > >> > >> > >>>The purpose should be to make proper data collection part > >>> > >>of the diameter > >> > >>>accounting off-loading thus the actual billing process. > >>> > >>Otherwise, if > >> > >>>diameter accounting does not offer proper data collection, > >>> > >>needed sanity > >> > >>>checks etc then in terms of accounting protocol would not > >>> > >>be offering > >> > >>>advantages over other accounting /collection mechanisms > >>> > >>which do offer > >> > >>>some of the above. Shouldn't the purpose of diameter > >>> > >>accounting be to > >> > >>>offer as reliable data collection as possible already within the > >>>protocol layer? Otherwise, relaying on the billing process > >>> > >>is something > >> > >>>that can be done without Diameter accounting. > >>> > >>Well, certain functions need to be performed between a service > >>and the bill from the service, but exactly where those happen > >>is a design issue. As far as other protocols possibly offering > >>some of these functions I can only repeat what I said earlier > >>about reordering, reboots etc. These don't appear to be issues > >>limited just to the Diameter protocol, they would apply to > >>other solutions as well. To me, the tradeoffs are pretty clearly > >>such that we should allow even reboot-damaged record streams > >>to come in. But others may disagree and apparently you do. > >>However, I'd like to point out that your product *can* ensure > >>ordering if it wants to - there may be service providers > >>that want to reduce the tasks of the billing post processing > >>phase at the expense of losing some records. > >> > >>In conclusion, you get what you want and I also get what I want. > >>However, if you want Diameter to *require* these checks then > >>you'll get what you want but I can't get what I want. So... > >> > >>>How is the server supposed to process differently those three > >>>different messages if their order does not make any sense? > >>> > >>I get the feeling that we are entering a philosophical discussion. > >>What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 > >>in a record state or not? It is stored in a file or data base > >>in the Diameter accounting server, so it should be considered > >>state. Similarly for the Accounting-Record-Type AVP, right? > >>All of this information is available for either immediate or > >>later processing. > >> > >>The only question is if we will decline receiving records in > >>order. > >> > >>>That should be stated in the doc so that "simple accounting" > >>>does not require state but "state related" accounting > >>>does require or in some better way ? > >>> > >>Perhaps this is our way to a compromise. Why don't we state > >>the situation about the potential immediate use or just > >>storage of the records in the document. For instance: > >> > >>"Note that the server side state machines requires the > >>reception of accounting records and does not place any > >>standards requirement on the processing of these records. > >>Implementations of Diameter MAY perform checking, ordering, > >>correlation, fraud detection, and other tasks based on > these records. > >>Both base Diameter AVPs as well as application specific > >>AVPs MAY be inspected as a part of these tasks. > >>The tasks can happen either immediately after record > >>reception or in a post-processing phase. However, as these > >>tasks are typically application or even policy dependent, > >>they are not standardized by the Diameter specifications." > >> > >>Jari > >> > > > > > > From owner-aaa-wg@merit.edu Thu Apr 4 08:39:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13814 for ; Thu, 4 Apr 2002 08:39:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE2F4912C9; Thu, 4 Apr 2002 08:39:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99A84912CA; Thu, 4 Apr 2002 08:39:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50DAE912C9 for ; Thu, 4 Apr 2002 08:39:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2953C5DDED; Thu, 4 Apr 2002 08:39:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 380395DDB4 for ; Thu, 4 Apr 2002 08:39:07 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g34CdZA07137 for ; Thu, 4 Apr 2002 14:39:35 +0200 Message-ID: <3CAC5752.5030406@ipunplugged.com> Date: Thu, 04 Apr 2002 15:38:26 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <142DC466081D9B409AAD1DDCA4B21E1D9E41BB@esebe016.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit You have no transport layer connection between the client and the accounting server. As for software bugs: assuming that they don't happen at a machine you don't control over is a good way to find trouble. You also forgot the case where a stop record due to reordering along the way arrives before and interim record. When the interim record arrives you will create a new session that will never receive a stop record. j marco.stura@nokia.com wrote: >what are the cases when stop record is not received? >I would say: > >1- network failure >2- Client error (e.g. spontaneous restart of the client, >Diameter process failure...) > >A network failure should be detected at the transport layer. >In general the accounting session will be closed if the transport layer >detect a connection failure (it is an implementation issue how transport >layer will instruct the Diameter layer). > >In case of client error sooner or later the transport layer connection >will be closed and we go back to the previous case. > >If the message is lost due to temporary network overload/failure >Diameter is running on reliable transport then the message will be >re-transmitted at transport layer. > >In case of software bug in the client the problem is not in the >server state model. > >Are these examples enough or you need more examples? > >BR >Marco > >>-----Original Message----- >>From: ext Johan Johansson [mailto:johanj@ipunplugged.com] >>Sent: 04. April 2002 16:03 >>To: Stura Marco (NET/Helsinki) >>Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); >>jari.arkko@kolumbus.fi; aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State >>Machines into Client vs. Server >> >> >>And what if no stop record is ever received? How does the server know >>that it can get rid of the session? >> >>j >> >>marco.stura@nokia.com wrote: >> >>>Hi Jari, >>> >>>I beleive it is not question of philosophical discussion at >>> >>all, if we have an accounting >> >>>session the state machine must be open. Idle means that we >>> >>don't have any ongoing >> >>>accounting session. It is definitely question of convention, >>> >>clarity and also >> >>>practicality. >>>I agree with your text, and this has to be written in the spec.: >>> >>>"Note that the server side state machines requires the >>>reception of accounting records and does not place any >>>standards requirement on the processing of these records. >>>Implementations of Diameter MAY perform checking, ordering, >>>correlation, fraud detection, and other tasks based on these records. >>>Both base Diameter AVPs as well as application specific >>>AVPs MAY be inspected as a part of these tasks. >>>The tasks can happen either immediately after record >>>reception or in a post-processing phase. However, as these >>>tasks are typically application or even policy dependent, >>>they are not standardized by the Diameter specifications." >>> >>>And I'm fine with the original Pete proposal for the >>> >>accounting session >> >>>state for the Server with minor addition, I still insist >>> >>that the state >> >>>must be Open when an accounting session is ongoing: >>> >>> SERVER, ACCOUNTING >>> State Event Action >>> >>New State >> >>---------------------------------------------------------------------- >> >>> Idle Accounting start request send Open >>> received, and successfully accounting >>> processed. start >>> answer >>> >>> Idle Accounting event request send Idle >>> received, and successfully accounting >>> processed. event >>> answer >>> >>> Idle Accounting request received send Idle >>> (Interim Record or Start req.) answer >>> no space left to store records Result-code= >>> out-of-space >>> >>> Idle Interim Record received send >>> >> Open >> >>> and successfully processed accounting >>> answer >>> >>> >>> Open Interim Record received send Open >>> and successfully processed accounting >>> answer >>> >>> Open Accounting stop request send Idle >>> received, and successfully accounting >>> processed stop answer >>> >>> Open Accounting request received send >>> >> Idle >> >>> (Interim Record or Stop req.) answer >>> no space left to store records Result-code= >>> out-of-space >>> >>> >>> >>>A little explanation of the addition I have done to the >>> >>original Pete proposal. >> >>>When there is no space left to store the record and the >>> >>accounting session is >> >>>Open the new state will be idle. If accounting request was >>> >>"Interim", the client >> >>>may not close the session when it receives the answer with >>> >>Result-code=out-of-space >> >>>(depending on the realtime AVP and client's buffer status) >>> >>thus the client >> >>>can still send subsequent interim record. >>>If the error condition is still active in the server when >>> >>subsequent interim records >> >>>are received the state will stay idle otherwise the session >>> >>is open again. >> >>>In general the possibility to receive interim record in idle >>> >>state is also useful >> >>>when the client need to send these records to an alternate >>> >>peer (server) in case >> >>>of accounting server failure. >>> >>>I hope everybody is happy with this simple state model that >>> >>clearly show, without >> >>>ambiguity, when the accounting session is open and when is not. >>> >>>BR >>>Marco >>> >>>>-----Original Message----- >>>>From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] >>>>Sent: 04. April 2002 12:21 >>>>To: Lialiamou Elena (NET-IMN/Helsinki) >>>>Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; aaa-wg@merit.edu >>>>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + >>>> >>Split State >> >>>>Machines into Client vs. Server >>>> >>>> >>>> >>>>>The purpose should be to make proper data collection part >>>>> >>>>of the diameter >>>> >>>>>accounting off-loading thus the actual billing process. >>>>> >>>>Otherwise, if >>>> >>>>>diameter accounting does not offer proper data collection, >>>>> >>>>needed sanity >>>> >>>>>checks etc then in terms of accounting protocol would not >>>>> >>>>be offering >>>> >>>>>advantages over other accounting /collection mechanisms >>>>> >>>>which do offer >>>> >>>>>some of the above. Shouldn't the purpose of diameter >>>>> >>>>accounting be to >>>> >>>>>offer as reliable data collection as possible already within the >>>>>protocol layer? Otherwise, relaying on the billing process >>>>> >>>>is something >>>> >>>>>that can be done without Diameter accounting. >>>>> >>>>Well, certain functions need to be performed between a service >>>>and the bill from the service, but exactly where those happen >>>>is a design issue. As far as other protocols possibly offering >>>>some of these functions I can only repeat what I said earlier >>>>about reordering, reboots etc. These don't appear to be issues >>>>limited just to the Diameter protocol, they would apply to >>>>other solutions as well. To me, the tradeoffs are pretty clearly >>>>such that we should allow even reboot-damaged record streams >>>>to come in. But others may disagree and apparently you do. >>>>However, I'd like to point out that your product *can* ensure >>>>ordering if it wants to - there may be service providers >>>>that want to reduce the tasks of the billing post processing >>>>phase at the expense of losing some records. >>>> >>>>In conclusion, you get what you want and I also get what I want. >>>>However, if you want Diameter to *require* these checks then >>>>you'll get what you want but I can't get what I want. So... >>>> >>>>>How is the server supposed to process differently those three >>>>>different messages if their order does not make any sense? >>>>> >>>>I get the feeling that we are entering a philosophical discussion. >>>>What is state anyway? Is the AVP value Acct-Output-Octets = 12031231 >>>>in a record state or not? It is stored in a file or data base >>>>in the Diameter accounting server, so it should be considered >>>>state. Similarly for the Accounting-Record-Type AVP, right? >>>>All of this information is available for either immediate or >>>>later processing. >>>> >>>>The only question is if we will decline receiving records in >>>>order. >>>> >>>>>That should be stated in the doc so that "simple accounting" >>>>>does not require state but "state related" accounting >>>>>does require or in some better way ? >>>>> >>>>Perhaps this is our way to a compromise. Why don't we state >>>>the situation about the potential immediate use or just >>>>storage of the records in the document. For instance: >>>> >>>>"Note that the server side state machines requires the >>>>reception of accounting records and does not place any >>>>standards requirement on the processing of these records. >>>>Implementations of Diameter MAY perform checking, ordering, >>>>correlation, fraud detection, and other tasks based on >>>> >>these records. >> >>>>Both base Diameter AVPs as well as application specific >>>>AVPs MAY be inspected as a part of these tasks. >>>>The tasks can happen either immediately after record >>>>reception or in a post-processing phase. However, as these >>>>tasks are typically application or even policy dependent, >>>>they are not standardized by the Diameter specifications." >>>> >>>>Jari >>>> >> >> >> > From owner-aaa-wg@merit.edu Thu Apr 4 09:34:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15997 for ; Thu, 4 Apr 2002 09:34:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3417E91264; Thu, 4 Apr 2002 09:34:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1EAD912CB; Thu, 4 Apr 2002 09:34:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63DB591264 for ; Thu, 4 Apr 2002 09:34:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F6095DE4D; Thu, 4 Apr 2002 09:34:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 820435DE53 for ; Thu, 4 Apr 2002 09:34:29 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34EYh528773 for ; Thu, 4 Apr 2002 17:34:43 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 17:34:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 17:34:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Thu, 4 Apr 2002 17:34:20 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E41BC@esebe016.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHb3id+ZsSDJNiyRKyzjWpJB6MyjwAA7R5Q From: To: Cc: X-OriginalArrivalTime: 04 Apr 2002 14:34:20.0762 (UTC) FILETIME=[CEDC43A0:01C1DBE5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15997 Diameter is running on TCP or SCTP (chapter 2.1), so there is TCP or SCTP reliable transport connection between client and server. And the case you describe is very very very improbable to happen. The client sends ACR (interim record) and goes to PendingI state. Now the user terminate the service then the client store the stop record (it does not send the stop record!)and stays in PendingI state untill it receives the ACA (interim record). When the ACA(interim record) has been successfully received the client goes to Open state then the client finally sends the ACA (stop record). So, ACA (stop record) is never sent by the client before the answer to the ACR (interim record) has not been received by the server, but this means that the server already received the request. I really don't see any problem, or better, the problem does not exist. BR Marco > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 04. April 2002 16:38 > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > You have no transport layer connection between the client and the > accounting server. As for software bugs: assuming that they > don't happen > at a machine you don't control over is a good way to find trouble. You > also forgot the case where a stop record due to reordering > along the way > arrives before and interim record. When the interim record arrives you > will create a new session that will never receive a stop record. > > j > > marco.stura@nokia.com wrote: > > >what are the cases when stop record is not received? > >I would say: > > > >1- network failure > >2- Client error (e.g. spontaneous restart of the client, > >Diameter process failure...) > > > >A network failure should be detected at the transport layer. > >In general the accounting session will be closed if the > transport layer > >detect a connection failure (it is an implementation issue > how transport > >layer will instruct the Diameter layer). > > > >In case of client error sooner or later the transport layer > connection > >will be closed and we go back to the previous case. > > > >If the message is lost due to temporary network overload/failure > >Diameter is running on reliable transport then the message will be > >re-transmitted at transport layer. > > > >In case of software bug in the client the problem is not in the > >server state model. > > > >Are these examples enough or you need more examples? > > > >BR > >Marco > > > >>-----Original Message----- > >>From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > >>Sent: 04. April 2002 16:03 > >>To: Stura Marco (NET/Helsinki) > >>Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > >>jari.arkko@kolumbus.fi; aaa-wg@merit.edu > >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + > Split State > >>Machines into Client vs. Server > >> > >> > >>And what if no stop record is ever received? How does the > server know > >>that it can get rid of the session? > >> > >>j > >> > >>marco.stura@nokia.com wrote: > >> > >>>Hi Jari, > >>> > >>>I beleive it is not question of philosophical discussion at > >>> > >>all, if we have an accounting > >> > >>>session the state machine must be open. Idle means that we > >>> > >>don't have any ongoing > >> > >>>accounting session. It is definitely question of convention, > >>> > >>clarity and also > >> > >>>practicality. > >>>I agree with your text, and this has to be written in the spec.: > >>> > >>>"Note that the server side state machines requires the > >>>reception of accounting records and does not place any > >>>standards requirement on the processing of these records. > >>>Implementations of Diameter MAY perform checking, ordering, > >>>correlation, fraud detection, and other tasks based on > these records. > >>>Both base Diameter AVPs as well as application specific > >>>AVPs MAY be inspected as a part of these tasks. > >>>The tasks can happen either immediately after record > >>>reception or in a post-processing phase. However, as these > >>>tasks are typically application or even policy dependent, > >>>they are not standardized by the Diameter specifications." > >>> > >>>And I'm fine with the original Pete proposal for the > >>> > >>accounting session > >> > >>>state for the Server with minor addition, I still insist > >>> > >>that the state > >> > >>>must be Open when an accounting session is ongoing: > >>> > >>> SERVER, ACCOUNTING > >>> State Event Action > >>> > >>New State > >> > > >>------------------------------------------------------------ > ---------- > >> > >>> Idle Accounting start request send Open > >>> received, and successfully accounting > >>> processed. start > >>> answer > >>> > >>> Idle Accounting event request send Idle > >>> received, and successfully accounting > >>> processed. event > >>> answer > >>> > >>> Idle Accounting request received send Idle > >>> > (Interim Record or Start req.) answer > >>> no space left to store records Result-code= > >>> out-of-space > >>> > >>> Idle > Interim Record received send > >>> > >> Open > >> > >>> > and successfully processed accounting > >>> answer > >>> > >>> > >>> Open Interim Record received send Open > >>> and successfully processed accounting > >>> answer > >>> > >>> Open Accounting stop request send Idle > >>> received, and successfully accounting > >>> processed stop answer > >>> > >>> Open > Accounting request received send > >>> > >> Idle > >> > >>> > (Interim Record or Stop req.) answer > >>> no space left to store records Result-code= > >>> out-of-space > >>> > >>> > >>> > >>>A little explanation of the addition I have done to the > >>> > >>original Pete proposal. > >> > >>>When there is no space left to store the record and the > >>> > >>accounting session is > >> > >>>Open the new state will be idle. If accounting request was > >>> > >>"Interim", the client > >> > >>>may not close the session when it receives the answer with > >>> > >>Result-code=out-of-space > >> > >>>(depending on the realtime AVP and client's buffer status) > >>> > >>thus the client > >> > >>>can still send subsequent interim record. > >>>If the error condition is still active in the server when > >>> > >>subsequent interim records > >> > >>>are received the state will stay idle otherwise the session > >>> > >>is open again. > >> > >>>In general the possibility to receive interim record in idle > >>> > >>state is also useful > >> > >>>when the client need to send these records to an alternate > >>> > >>peer (server) in case > >> > >>>of accounting server failure. > >>> > >>>I hope everybody is happy with this simple state model that > >>> > >>clearly show, without > >> > >>>ambiguity, when the accounting session is open and when is not. > >>> > >>>BR > >>>Marco > >>> > >>>>-----Original Message----- > >>>>From: ext Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > >>>>Sent: 04. April 2002 12:21 > >>>>To: Lialiamou Elena (NET-IMN/Helsinki) > >>>>Cc: jari.arkko@kolumbus.fi; johanj@ipunplugged.com; > aaa-wg@merit.edu > >>>>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + > >>>> > >>Split State > >> > >>>>Machines into Client vs. Server > >>>> > >>>> > >>>> > >>>>>The purpose should be to make proper data collection part > >>>>> > >>>>of the diameter > >>>> > >>>>>accounting off-loading thus the actual billing process. > >>>>> > >>>>Otherwise, if > >>>> > >>>>>diameter accounting does not offer proper data collection, > >>>>> > >>>>needed sanity > >>>> > >>>>>checks etc then in terms of accounting protocol would not > >>>>> > >>>>be offering > >>>> > >>>>>advantages over other accounting /collection mechanisms > >>>>> > >>>>which do offer > >>>> > >>>>>some of the above. Shouldn't the purpose of diameter > >>>>> > >>>>accounting be to > >>>> > >>>>>offer as reliable data collection as possible already within the > >>>>>protocol layer? Otherwise, relaying on the billing process > >>>>> > >>>>is something > >>>> > >>>>>that can be done without Diameter accounting. > >>>>> > >>>>Well, certain functions need to be performed between a service > >>>>and the bill from the service, but exactly where those happen > >>>>is a design issue. As far as other protocols possibly offering > >>>>some of these functions I can only repeat what I said earlier > >>>>about reordering, reboots etc. These don't appear to be issues > >>>>limited just to the Diameter protocol, they would apply to > >>>>other solutions as well. To me, the tradeoffs are pretty clearly > >>>>such that we should allow even reboot-damaged record streams > >>>>to come in. But others may disagree and apparently you do. > >>>>However, I'd like to point out that your product *can* ensure > >>>>ordering if it wants to - there may be service providers > >>>>that want to reduce the tasks of the billing post processing > >>>>phase at the expense of losing some records. > >>>> > >>>>In conclusion, you get what you want and I also get what I want. > >>>>However, if you want Diameter to *require* these checks then > >>>>you'll get what you want but I can't get what I want. So... > >>>> > >>>>>How is the server supposed to process differently those three > >>>>>different messages if their order does not make any sense? > >>>>> > >>>>I get the feeling that we are entering a philosophical > discussion. > >>>>What is state anyway? Is the AVP value > Acct-Output-Octets = 12031231 > >>>>in a record state or not? It is stored in a file or data base > >>>>in the Diameter accounting server, so it should be considered > >>>>state. Similarly for the Accounting-Record-Type AVP, right? > >>>>All of this information is available for either immediate or > >>>>later processing. > >>>> > >>>>The only question is if we will decline receiving records in > >>>>order. > >>>> > >>>>>That should be stated in the doc so that "simple accounting" > >>>>>does not require state but "state related" accounting > >>>>>does require or in some better way ? > >>>>> > >>>>Perhaps this is our way to a compromise. Why don't we state > >>>>the situation about the potential immediate use or just > >>>>storage of the records in the document. For instance: > >>>> > >>>>"Note that the server side state machines requires the > >>>>reception of accounting records and does not place any > >>>>standards requirement on the processing of these records. > >>>>Implementations of Diameter MAY perform checking, ordering, > >>>>correlation, fraud detection, and other tasks based on > >>>> > >>these records. > >> > >>>>Both base Diameter AVPs as well as application specific > >>>>AVPs MAY be inspected as a part of these tasks. > >>>>The tasks can happen either immediately after record > >>>>reception or in a post-processing phase. However, as these > >>>>tasks are typically application or even policy dependent, > >>>>they are not standardized by the Diameter specifications." > >>>> > >>>>Jari > >>>> > >> > >> > >> > > > > > > > From owner-aaa-wg@merit.edu Thu Apr 4 09:54:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17223 for ; Thu, 4 Apr 2002 09:54:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84CD3912CB; Thu, 4 Apr 2002 09:54:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4B2912CC; Thu, 4 Apr 2002 09:54:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11B17912CB for ; Thu, 4 Apr 2002 09:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id E25B15DDB3; Thu, 4 Apr 2002 09:54:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 44EED5DDAB for ; Thu, 4 Apr 2002 09:54:36 -0500 (EST) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g34Esa805570; Thu, 4 Apr 2002 16:54:36 +0200 Message-ID: <3CAC6902.6030708@ipunplugged.com> Date: Thu, 04 Apr 2002 16:53:54 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <142DC466081D9B409AAD1DDCA4B21E1D9E41BC@esebe016.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com wrote: >Diameter is running on TCP or SCTP (chapter 2.1), so there is TCP or >SCTP reliable transport connection between client and server. > No. There is one between each node in the network but rarely directly between the client and the server. This means that the server must be able to handle the case where no stop record is ever sent and therefore not received without involving transport layer events (which is why they are not in the state machine). >And the case you describe is very very very improbable to happen. > >The client sends ACR (interim record) and goes to PendingI state. >Now the user terminate the service then the client store the stop >record (it does not send the stop record!)and stays in PendingI >state untill it receives the ACA (interim record). >When the ACA(interim record) has been successfully received the >client goes to Open state then the client finally sends the >ACA (stop record). > >So, ACA (stop record) is never sent by the client before the >answer to the ACR (interim record) has not been received by the >server, but this means that the server already received the >request. > So when you are sending accounting records on startup that have been saved in persistant storage as a part of fault recovery you replay the session's lifetime in fast-forward? If you do that, wouldn't you need to store the client side session state along with every accounting record? j From owner-aaa-wg@merit.edu Thu Apr 4 10:33:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18798 for ; Thu, 4 Apr 2002 10:33:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 231449120F; Thu, 4 Apr 2002 10:33:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E94DD912CC; Thu, 4 Apr 2002 10:33:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C07E39120F for ; Thu, 4 Apr 2002 10:33:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D4695DDB3; Thu, 4 Apr 2002 10:33:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 888325DD9B for ; Thu, 4 Apr 2002 10:33:16 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 444816C; Thu, 4 Apr 2002 10:33:16 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: [Fwd: Issue #299 and #301] Date: Thu, 4 Apr 2002 10:32:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3CABB80A.1DCC1BA@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > > > > > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > > > returned to the AAAH. > > > > Since this is a RADIUS attribute, it'd be a good idea to retain > > the RADIUS name, i.e. "Acct-Multi-Session-Id". > > Good catch. Please make a new issue to the BASE. Already done. This was part of Issue#314: Minor clarifications/corrections to Base-09. Bob K. From owner-aaa-wg@merit.edu Thu Apr 4 11:29:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21444 for ; Thu, 4 Apr 2002 11:29:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD265912E3; Thu, 4 Apr 2002 11:28:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA688912E2; Thu, 4 Apr 2002 11:28:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68CAE912D1 for ; Thu, 4 Apr 2002 11:28:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49F2C5DE68; Thu, 4 Apr 2002 11:28:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 30E215DE2B for ; Thu, 4 Apr 2002 11:28:26 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id E32DB6C; Thu, 4 Apr 2002 11:28:25 -0500 (EST) From: "Bob Kopacz" To: "Johan Johansson" Cc: "Tony Johansson" , "David Spence" , "aaa-wg" Subject: RE: [AAA-WG]: Re: [Fwd: Issue #299 and #301] Date: Thu, 4 Apr 2002 11:27:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3CAC23F6.9060505@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan and Tony, Here's some partial feedback on the specific subissue of using a single AAAH over the life of a MN session. > ................................................. > > >>Furthermore, the nature of mobile IP also means that the mobile node > >>will do handoffs between different foreign agents and to guarantee > >>that a registered user always ends up in the same initial AAAH the > >>Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to > >>assist the AAAH in routing the messages to a mobile node's home agent > >>the mobile node MUST always include the HA NAI [AAANAI]. > > > >--> The plan, then, is that exactly one AAAH will be employed for the > >life of a MN's session. And if that AAAH becomes unavailable, it is > >"game over" for the MN's session, even if other AAAHs are available? If > >this is true, should this be explicitly stated? > > How about not breaking what was not previously broken instead? I will > consider anything that requires that the same AAAH be used throughout > the mobile node's session a showstopper bug. If you for some reason > *prefer* that an MN use the same AAAH throughout the session then by all > means introduce this redundant functionality as a MAY. You are right, this does introduce a new single point of failure. More complete comments at next break point. > ................................................. > > >>A mobile node, which has been previously authenticated andauthorized, > >>MUST always include the assigned home agent in the HA-NAI > >>and the authorizing Home AAA server in the AAAH-NAI in the > >>registration request message [AAANAI] sent to the FA, every time the > >>Mobile Node needs to re-authenticating. So, in the event that the AMR > >>generated by the FA is for a session that has was previously > >>authorized, it MUST include the Destination-Host AVP, with the > >>identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- > >>Host AVP the identity of the assigned HA found in the HA-NAI. > >> > > > >--> Replace the above paragraph (due to various typos) with: > > > > "A mobile node, which has been previously authenticated and authorized, > > MUST always include the assigned home agent in the HA Identity subtype > > of the AAA NAI extension, and the authorizing Home AAA server in the > > AAAH Identity subtype of the AAA NAI extension, in the registration > > request message [AAANAI] which is sent to the FA every time the Mobile > > Node needs to re-authenticate. So, in the event that the AMR generated > > by the FA is for a session that was previously authorized, it MUST > > include the Destination-Host AVP, with the identity of the AAAH found in > > the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and > > realm of the assigned HA found in the HA-NAI." > > > I don't understand why you have chosen to make this fundamental > restriction in the protocol? The only think that must remain constant > during a session is the home agent and the HA-NAI part is then of course > needed to make the protocol work, but why introduce the AAAH NAI just to > make the protocol less capable? I think (but am not sure) the reason the proposed text states that a single AAAH be used over the life of a MN session is this: In earlier discussions of issue#299, the AMR carried only the HA's IP address and not the HA's identity. After a handoff to a new foreign domain where the MN wanted to retain the foreign HA in the first-visited foreign domain, the AAAH had to somehow map the HA's IP address into an HA identity+realm, so that the AAAH could route the HAR to the HA. This presented a problem for the AAAH. But if the AAAH is session-stateful, and the same AAAH is used over the life of the MN session, then the AAAH could just retreive the HA's identity+realm from his internal state information. Problem solved. But a new AAAH without this cached state information would still have the "mapping HA IP Address to Identity+Realm" problem. However, now that the handoff AMR contains the HA's identity+realm, a new AAAH doesn't have this problem. So it seems that the need to employ a single AAAH over the life of a session is gone, at least in terms of the "mapping HA IP Address to Identity+Realm" snag. One thing that a new AAAH doesn't have, however, is the identity+realm of the destination AAAF hosting the foreign HA. A single session-stateful AAAH employed over the life of a MN's session would have this destination-AAAF-identity information as part of his session state. If the AAAH needs to know the destination-AAAF's identity for the purpose of securing session keys, then this presents a problem for a new AAAH. > > ................................................. > > >--> I also like the idea of the the originating AAAF *always* including > >his identity in an AMR, whether including a Candidate-MIP-HA or not. > >This has two virtues: > > > >1. The AAAH and HA always have a fixed place to look for the FA's > >identity. > > > I suppose you mean the AAAF's identity? Yes. I thought "AAAF" but typed "FA". Same letters involved :) > >2. The AAAH can be assured that the AMR has actually passed through an > >AAAF on the way, and thus that the foreign network had its opportunity > >to apply its policy. What I mean is this: When the FA sends an AMR, it > >is routed by Destination-Realm. Suppose the FA has a Relay between > >itself and the local AAAF. The FA sends the AMR to the Relay. If the > >Relay's routing is misconfigured, the Relay may just route the AMR > >directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary > >know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA > >AVP was required but not present, this would tip off the AAAH that > >something was amiss. > > If we agree to say that a AAAF must add it's identity upon processing a > message then I have no objections. But if you are saying that a network > MUST have a AAAF I disagree. Consequently the AAAH can't know if > something is amiss or not. Are you saying that a visited foreign network could have FAs but no AAAFs? I didn't know that. My understanding of the "real world" scenarios is frequently more limited than I'd like. > ................................................. From owner-aaa-wg@merit.edu Thu Apr 4 11:39:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21890 for ; Thu, 4 Apr 2002 11:39:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B28F912CE; Thu, 4 Apr 2002 11:39:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A9F5912D0; Thu, 4 Apr 2002 11:39:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D14A0912CE for ; Thu, 4 Apr 2002 11:39:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B340A5DE68; Thu, 4 Apr 2002 11:39:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 7D0905DE2B for ; Thu, 4 Apr 2002 11:39:11 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g34Gd7D17064; Thu, 4 Apr 2002 11:39:08 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA03614; Thu, 4 Apr 2002 10:39:07 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g34Gd5814912; Thu, 4 Apr 2002 10:39:05 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15532.33192.903156.368613@nwsgpc.ih.lucent.com> Date: Thu, 4 Apr 2002 10:39:04 -0600 (CST) From: Pete McCann To: Jari Arkko Cc: Elena.Lialiamou@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server In-Reply-To: <3CAC1AEA.AD3184C3@lmf.ericsson.se> References: <93532512B06FC3489824C18037DB3D4B7B75CD@esebe015.NOE.Nokia.com> <3CAC1AEA.AD3184C3@lmf.ericsson.se> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jari Arkko writes: > Perhaps this is our way to a compromise. Why don't we state > the situation about the potential immediate use or just > storage of the records in the document. For instance: > > "Note that the server side state machines requires the > reception of accounting records and does not place any > standards requirement on the processing of these records. > Implementations of Diameter MAY perform checking, ordering, > correlation, fraud detection, and other tasks based on these records. > Both base Diameter AVPs as well as application specific > AVPs MAY be inspected as a part of these tasks. > The tasks can happen either immediately after record > reception or in a post-processing phase. However, as these > tasks are typically application or even policy dependent, > they are not standardized by the Diameter specifications." I think this text is quite reasonable, and I would even support removing the state machine entirely and replacing it with this text and a bit of explanation. The only reason my original proposal had an "Open" state was because it was a cut-and-paste of what was already there. However, after reading the discussion on the issue, I don't think we should place any requirements on the order in which accounting records arrive at the accounting server, which is what a state machine would essentially do. State machines define sets of acceptable event strings, and by definition other strings are not acceptable. I think the discussion has shown that there is no reasonable way to react differently to an "unacceptable" string of events because there may not be any connection to the authorization state machine. The server might throw away the entire string, but personally I think it's better to keep it so you can try to figure out what happened later. -Pete From owner-aaa-wg@merit.edu Thu Apr 4 11:40:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21961 for ; Thu, 4 Apr 2002 11:40:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F99B912D0; Thu, 4 Apr 2002 11:40:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D002912D1; Thu, 4 Apr 2002 11:40:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA3BC912D0 for ; Thu, 4 Apr 2002 11:40:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 906385DE68; Thu, 4 Apr 2002 11:40:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 61CF15DE2B for ; Thu, 4 Apr 2002 11:40:25 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 43546E00091; Thu, 4 Apr 2002 08:40:21 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id IAA08957; Thu, 4 Apr 2002 08:41:04 -0800 (PST) Date: Thu, 4 Apr 2002 08:41:02 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: Tony Johansson , Joe Lau , AAA Working Group Subject: RE: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Fredrick, > >This is different from the two implementations I was referring in my > >original email: > > > >1. The HA implementation maintains only one key to the FA. Everytime > >it get a new key to the FA, it will refresh the existing key (if any) > >and assign the same SPI to the new key. This is the only key that will > >be used for all communication between the FA and HA. (corresponds to > >"any key") > > But this is a illegal behavior, what if the message distributing the keys to > the FA gets lost on its way? Consider the case where the HA receives a new > key for the FA and refreshes the existing key and assigns the same SPI (as > you indicate) to the new key. If the FA does not receive the new key it will > try to use the old key which still might be valid since it should request > new keys sometime before the old one expires. When the request reaches the > HA it will check what key to use by looking at the SPI, the HA will now take > the new key since it has already replaced the old one, i.e. you get an > authentication failure just beacause the HA replaced the key for that SPI. true. > > > >2. The FA implementation maintains HA-FA key for each session, which > >is the one and only key that can be used for any communication between > >the FA and HA for that session -- the FA will expect the authenticator > >from the HA to have been created only using that session's key (and > >SPI). (corresponds to "session key"). > > The FA-HA keys does not have anything todo with the session, the session > might just be the one that distributes the key. A Security Association is > between a pair of nodes. When the FA should authenticate a mip msg it looks > at the SPI to find a Security Context within the Mobility Security > Association that exists between the FA and the node that sent the message. > It may very well be so that every session adds a new Security Context to the > Mobility Security Association, but they are all valid for any session > between these nodes. Each Context may have a lifetime similar to that of the > session that added it, but there is nothing in the context that tells the FA > which session that added it. This IS more in line with base Mobile IP. However, if the FA-HA key does not have anything to do with the session, then it seems like the key-lifetime rule wrt termination of session (section 6.13) may not be applicable to it!! Anyway, greatly appreciate your detailed clarification here. Siva From owner-aaa-wg@merit.edu Thu Apr 4 12:11:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23533 for ; Thu, 4 Apr 2002 12:11:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 505D9912D1; Thu, 4 Apr 2002 12:10:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21C91912D2; Thu, 4 Apr 2002 12:10:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A85D912D1 for ; Thu, 4 Apr 2002 12:10:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A96C5DE6B; Thu, 4 Apr 2002 12:10:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 4C98F5DD95 for ; Thu, 4 Apr 2002 12:10:47 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id E1854E009D0; Thu, 4 Apr 2002 09:10:46 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA09088; Thu, 4 Apr 2002 09:11:31 -0800 (PST) Date: Thu, 4 Apr 2002 09:11:30 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Johan Johansson Cc: AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host In-Reply-To: <3CAC0941.8010105@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, 4 Apr 2002, Johan Johansson wrote: > Sivasundar Ramamurthy wrote: > > >>In any case, the HA does not know which ip > >>address to use for it's SA with the FA. > >> > >>Note that this means that any implementation that assumes that it knows > >>how to key the SA is *severly broken*. > >> > >>I can see 3 different solutions to this problem. > >> > >> 1. Make the MIP-Foreign-Agent-Host avp a MIP-Foreign-Agent-Address > >> avp and make it mandatory in the AMR and HAR. > >> > > > >This will work but might require the FA has to use the same > >control interface to forward all reg requests to this HA. This is > >needed if the HA has multiple SAs to the same FA and can expect the FA > >to use any of these SAs. > > > The interface could be changed by performing a new Diameter > authorization and requesting a new set of keys. So the FA and HA will maintain the both endpoints of the FA-HA SA as IP addresses, not as FQDNs -- something like "This key is only between this address of mine to this address (of some FA)". > >> 2. Since the UDP header is part of the MobileIP protocol, include the > >> UDP header in the MIP-Reg-Request avp > >> > > > >This may not work since the AAA authentication will fail for the MN, > >unless the header is added after the MN-AAA auth ext (if that makes > >sense at all!) > > > Why would it fail? Obviously, the fact that there is an UDP header > present needs to be taken into account whenever the MIP-Reg-Request is used. I am not clear on which UDP header are we talking about. Is it the header in the request sent by the MN, or the header that would be used if the request was forwarded by the FA as a UDP packet? MN authentication by AAA is based on the MAC in the MN-AAA authenticator. When the MN creates the authenticator, it would have calculated the MAC starting from the MIP reg header. If the FA adds the UDP header to this AVP, then the MAC calculated by the AAA server will not be the same. Unless the UDP header is the one in the request sent by the MN, and the MN includes the UDP header in calculating the MN-AAA MAC, this may not work. Or am I missing something here? :-) > >> 3. Demand that the CoA is used to key SAs in MobileIP (fat chance - > >> but it is a possible solution) > >> > >Another solution is retaining the FA-Host AVP and having the FA > >include its NAI in a FA-NAI extension in the UDP request. This ext > >MUST be used if a AAA distributed FA-HA key is used. This will let the > >HA key the SA on the FQDN of the FA instead of IP address. > > > That would prevent using aliases, so if anything you'd need to key it on > the ip address that you get by resolving that particular FQDN. I am a > bit confused about why you'd want to retain the FA-Host AVP while at the > same time sending similar information at the MobileIP level? If the > FA-Host AVP were to be retained it would most certainly have to be > supplied by the FA itself and not taken from the Origin-Host avp of the > AMR. But if what you will eventually need is an IP address why not send > an IP address? If the key is stored against an IP address, then using the FQDN still needs DNS resolution, which we have accepted as not totally reliable. So this "usage" can also be thrown out. And yes, the FA-Host AVP would be redundant if the same info is send in the MIP level. > Further investigation by Fredrik in the MobileIP RFC reveals that it is > undefined which IP address to use when looking up SAs. It is defined for > the SA between MN and HA, but *not* for FA and HA. It simply says that > it must be an IP address. This is of course a source of interopability > problems that needs to be dealt with. Our local Mobile IP guy exclaimed > with surprise for instance "It's not the CoA?" Agree 100%. If we do store the FA-HA key against an IP-address, and not host names, your solution #1 might be the way to go. thanks, Siva From owner-aaa-wg@merit.edu Thu Apr 4 12:41:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24923 for ; Thu, 4 Apr 2002 12:41:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C515912D2; Thu, 4 Apr 2002 12:41:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35B06912D3; Thu, 4 Apr 2002 12:41:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E53C4912D2 for ; Thu, 4 Apr 2002 12:41:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C44F45DE2B; Thu, 4 Apr 2002 12:41:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 8ACFB5DE0D for ; Thu, 4 Apr 2002 12:41:00 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 762326A907; Thu, 4 Apr 2002 20:40:55 +0300 (EEST) Message-ID: <3CAC827D.1070900@kolumbus.fi> Date: Thu, 04 Apr 2002 19:42:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: marco.stura@nokia.com Cc: johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server References: <142DC466081D9B409AAD1DDCA4B21E1D9E41BC@esebe016.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com wrote: > Diameter is running on TCP or SCTP (chapter 2.1), so there is TCP or > SCTP reliable transport connection between client and server. Only if the client and the server are adjacent to each other. If there's a proxy in between there's no way to know for sure what's happeningv at the other end. Jari From owner-aaa-wg@merit.edu Thu Apr 4 16:44:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09958 for ; Thu, 4 Apr 2002 16:44:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A4B959121C; Thu, 4 Apr 2002 16:44:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76DF9912D6; Thu, 4 Apr 2002 16:44:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCACB9121C for ; Thu, 4 Apr 2002 16:44:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id C576B5DE79; Thu, 4 Apr 2002 16:44:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 611DC5DE75 for ; Thu, 4 Apr 2002 16:44:25 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g34LiNi02348; Thu, 4 Apr 2002 15:44:24 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g34LiMn25909; Thu, 4 Apr 2002 15:44:22 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA25754; Thu, 4 Apr 2002 15:44:22 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA21852; Thu, 4 Apr 2002 15:44:20 -0600 (CST) Message-ID: <3CACC887.9285EAED@ericsson.com> Date: Thu, 04 Apr 2002 13:41:27 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Johan Johansson , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob and Johan, To really try to clarify this. We are in worst case talking about a single point of failure for a MN's session. However, this is a limitation already imposed today in the MIP application, which stated - "In the event that the AMR generated by the FA is for a session that has was previously authorized by the AAAH, it MUST include the Destination-Host AVP". So, to be very explicit, we are not introducing any new limitations with this new functionality design to handle both issue#299 and #301. Regardless, this perceived limitation (single point of failure for a MN's session) can be overcome by utilizing the fail over mechanisms described in Base. IMHO, since the failover mechanisms are described in the Base there is no need to discuss them in the MIP application. To support the failover mechanisms in Base, the following clarification should be added in [AAANAI]: " 5. AAAH Identity subtype .... A mobile node MUST always save the AAAH Identity received in the registration reply message and MUST provide the AAAH Identity in every registration request sent when re-authenticating. .... " Any comments / objections to this. /Tony Bob Kopacz wrote: > Hi Johan and Tony, > > Here's some partial feedback on the specific subissue of using > a single AAAH over the life of a MN session. > > > ................................................. > > > > >>Furthermore, the nature of mobile IP also means that the mobile node > > >>will do handoffs between different foreign agents and to guarantee > > >>that a registered user always ends up in the same initial AAAH the > > >>Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to > > >>assist the AAAH in routing the messages to a mobile node's home agent > > >>the mobile node MUST always include the HA NAI [AAANAI]. > > > > > >--> The plan, then, is that exactly one AAAH will be employed for the > > >life of a MN's session. And if that AAAH becomes unavailable, it is > > >"game over" for the MN's session, even if other AAAHs are available? If > > >this is true, should this be explicitly stated? > > > > How about not breaking what was not previously broken instead? I will > > consider anything that requires that the same AAAH be used throughout > > the mobile node's session a showstopper bug. If you for some reason > > *prefer* that an MN use the same AAAH throughout the session then by all > > means introduce this redundant functionality as a MAY. > > You are right, this does introduce a new single point of failure. > > More complete comments at next break point. > > > ................................................. > > > > >>A mobile node, which has been previously authenticated andauthorized, > > >>MUST always include the assigned home agent in the HA-NAI > > >>and the authorizing Home AAA server in the AAAH-NAI in the > > >>registration request message [AAANAI] sent to the FA, every time the > > >>Mobile Node needs to re-authenticating. So, in the event that the AMR > > >>generated by the FA is for a session that has was previously > > >>authorized, it MUST include the Destination-Host AVP, with the > > >>identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent- > > >>Host AVP the identity of the assigned HA found in the HA-NAI. > > >> > > > > > >--> Replace the above paragraph (due to various typos) with: > > > > > > "A mobile node, which has been previously authenticated and authorized, > > > MUST always include the assigned home agent in the HA Identity subtype > > > of the AAA NAI extension, and the authorizing Home AAA server in the > > > AAAH Identity subtype of the AAA NAI extension, in the registration > > > request message [AAANAI] which is sent to the FA every time the Mobile > > > Node needs to re-authenticate. So, in the event that the AMR generated > > > by the FA is for a session that was previously authorized, it MUST > > > include the Destination-Host AVP, with the identity of the AAAH found in > > > the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and > > > realm of the assigned HA found in the HA-NAI." > > > > > I don't understand why you have chosen to make this fundamental > > restriction in the protocol? The only think that must remain constant > > during a session is the home agent and the HA-NAI part is then of course > > needed to make the protocol work, but why introduce the AAAH NAI just to > > make the protocol less capable? > > I think (but am not sure) the reason the proposed text states that a > single AAAH be used over the life of a MN session is this: In earlier > discussions of issue#299, the AMR carried only the HA's IP address and > not the HA's identity. After a handoff to a new foreign domain where > the MN wanted to retain the foreign HA in the first-visited foreign > domain, the AAAH had to somehow map the HA's IP address into an HA > identity+realm, so that the AAAH could route the HAR to the HA. This > presented a problem for the AAAH. But if the AAAH is session-stateful, > and the same AAAH is used over the life of the MN session, then the AAAH > could just retreive the HA's identity+realm from his internal state > information. Problem solved. But a new AAAH without this cached state > information would still have the "mapping HA IP Address to > Identity+Realm" problem. > > However, now that the handoff AMR contains the HA's identity+realm, a > new AAAH doesn't have this problem. So it seems that the need to employ > a single AAAH over the life of a session is gone, at least in terms of > the "mapping HA IP Address to Identity+Realm" snag. > > One thing that a new AAAH doesn't have, however, is the identity+realm > of the destination AAAF hosting the foreign HA. A single > session-stateful AAAH employed over the life of a MN's session would > have this destination-AAAF-identity information as part of his session > state. If the AAAH needs to know the destination-AAAF's identity for > the purpose of securing session keys, then this presents a problem for a > new AAAH. > > > > > ................................................. > > > > >--> I also like the idea of the the originating AAAF *always* including > > >his identity in an AMR, whether including a Candidate-MIP-HA or not. > > >This has two virtues: > > > > > >1. The AAAH and HA always have a fixed place to look for the FA's > > >identity. > > > > > I suppose you mean the AAAF's identity? > > Yes. I thought "AAAF" but typed "FA". Same letters involved :) > > > >2. The AAAH can be assured that the AMR has actually passed through an > > >AAAF on the way, and thus that the foreign network had its opportunity > > >to apply its policy. What I mean is this: When the FA sends an AMR, it > > >is routed by Destination-Realm. Suppose the FA has a Relay between > > >itself and the local AAAF. The FA sends the AMR to the Relay. If the > > >Relay's routing is misconfigured, the Relay may just route the AMR > > >directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary > > >know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA > > >AVP was required but not present, this would tip off the AAAH that > > >something was amiss. > > > > If we agree to say that a AAAF must add it's identity upon processing a > > message then I have no objections. But if you are saying that a network > > MUST have a AAAF I disagree. Consequently the AAAH can't know if > > something is amiss or not. > > Are you saying that a visited foreign network could have FAs but no AAAFs? > I didn't know that. My understanding of the "real world" scenarios is > frequently more limited than I'd like. > > > ................................................. From owner-aaa-wg@merit.edu Thu Apr 4 18:04:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12111 for ; Thu, 4 Apr 2002 18:04:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5EBE9121E; Thu, 4 Apr 2002 18:04:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8803A912D7; Thu, 4 Apr 2002 18:04:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CEE69121E for ; Thu, 4 Apr 2002 18:04:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 312665DD9B; Thu, 4 Apr 2002 18:04:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 68AFE5DD92 for ; Thu, 4 Apr 2002 18:03:59 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020404230358.KPLF25793.fep02-svc.swip.net@ipunplugged.com>; Fri, 5 Apr 2002 01:03:58 +0200 Message-ID: <3CACDC26.1060408@ipunplugged.com> Date: Fri, 05 Apr 2002 01:05:10 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >However, now that the handoff AMR contains the HA's identity+realm, a >new AAAH doesn't have this problem. So it seems that the need to employ >a single AAAH over the life of a session is gone, at least in terms of >the "mapping HA IP Address to Identity+Realm" snag. > Yes. I agree that it in some cases might make things a bit smoother, but I think this should be optional since the protocol does seem to work well without it. >One thing that a new AAAH doesn't have, however, is the identity+realm >of the destination AAAF hosting the foreign HA. A single >session-stateful AAAH employed over the life of a MN's session would >have this destination-AAAF-identity information as part of his session >state. If the AAAH needs to know the destination-AAAF's identity for >the purpose of securing session keys, then this presents a problem for a >new AAAH. > Here you and Tony have dug in way more deeply than I. If all you need is the identity of the AAAF you should direct your HAR to, wouldn't the Mip-Originating-Foreign-AAA AVP suffice if you require the AAAF to add it if a AAAF is present (otherwise the problem obviously doesn't exist)? >>>2. The AAAH can be assured that the AMR has actually passed through an >>>AAAF on the way, and thus that the foreign network had its opportunity >>>to apply its policy. What I mean is this: When the FA sends an AMR, it >>>is routed by Destination-Realm. Suppose the FA has a Relay between >>>itself and the local AAAF. The FA sends the AMR to the Relay. If the >>>Relay's routing is misconfigured, the Relay may just route the AMR >>>directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary >>>know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA >>>AVP was required but not present, this would tip off the AAAH that >>>something was amiss. >>> >> >>If we agree to say that a AAAF must add it's identity upon processing a >>message then I have no objections. But if you are saying that a network >>MUST have a AAAF I disagree. Consequently the AAAH can't know if >>something is amiss or not. >> > >Are you saying that a visited foreign network could have FAs but no AAAFs? >I didn't know that. My understanding of the "real world" scenarios is >frequently more limited than I'd like. > Well... "real world" scenarios are so far pretty scarce. But there is nothing that I know of that requires a AAAF to exist unless you want to allow allocation of HAs for visitors. This shouldn't be interpreted as if I don't like AAAFs, but I think that for a significant subset of deployments the foreign network doesn't have to have one. And, as you know I've been lobbying, if not on the wg list, for some "real world" networks to be built before the standard goes to an RFC but I guess it wasn't to be. j From owner-aaa-wg@merit.edu Thu Apr 4 18:19:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12468 for ; Thu, 4 Apr 2002 18:19:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1E46912DA; Thu, 4 Apr 2002 18:18:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF630912DB; Thu, 4 Apr 2002 18:18:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70837912DA for ; Thu, 4 Apr 2002 18:18:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56BD45DDBB; Thu, 4 Apr 2002 18:18:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id B48EA5DD9B for ; Thu, 4 Apr 2002 18:18:14 -0500 (EST) Received: from ipunplugged.com ([213.100.60.194]) by fep04-svc.swip.net with ESMTP id <20020404231813.KETK16729.fep04-svc.swip.net@ipunplugged.com>; Fri, 5 Apr 2002 01:18:13 +0200 Message-ID: <3CACDF7D.6060105@ipunplugged.com> Date: Fri, 05 Apr 2002 01:19:25 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: AAA Working Group Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sivasundar Ramamurthy wrote: >>>> 2. Since the UDP header is part of the MobileIP protocol, include the >>>> UDP header in the MIP-Reg-Request avp >>>> >>>This may not work since the AAA authentication will fail for the MN, >>>unless the header is added after the MN-AAA auth ext (if that makes >>>sense at all!) >>> >>Why would it fail? Obviously, the fact that there is an UDP header >>present needs to be taken into account whenever the MIP-Reg-Request is used. >> > >I am not clear on which UDP header are we talking about. Is it the >header in the request sent by the MN, or the header that would be used >if the request was forwarded by the FA as a UDP packet? > >MN authentication by AAA is based on the MAC in the MN-AAA >authenticator. When the MN creates the authenticator, it would have >calculated the MAC starting from the MIP reg header. If the FA adds >the UDP header to this AVP, then the MAC calculated by the AAA server >will not be the same. > >Unless the UDP header is the one in the request sent by the MN, and >the MN includes the UDP header in calculating the MN-AAA MAC, >this may not work. > >Or am I missing something here? :-) > I was talking about the header that would have been added by the FA if the request had been forwarded as a UDP packet. The AAA server must then skip a UDP header at the beginning when calculating its MAC. I'm not saying that this is the optimal solution, but it seems to work in theory (I think). j From owner-aaa-wg@merit.edu Thu Apr 4 18:43:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12873 for ; Thu, 4 Apr 2002 18:43:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A88F2912DB; Thu, 4 Apr 2002 18:43:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DEDD912DC; Thu, 4 Apr 2002 18:43:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43A09912DB for ; Thu, 4 Apr 2002 18:43:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B9225DE6B; Thu, 4 Apr 2002 18:43:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 068EF5DD92 for ; Thu, 4 Apr 2002 18:43:04 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 907A66C; Thu, 4 Apr 2002 18:42:53 -0500 (EST) From: "Bob Kopacz" To: "Johan Johansson" Cc: "Tony Johansson" , "David Spence" , "aaa-wg" Subject: RE: [AAA-WG]: Re: [Fwd: Issue #299 and #301] Date: Thu, 4 Apr 2002 18:41:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3CACDC26.1060408@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan and Tony, # From: Johan Johansson [johanj@ipunplugged.com] # Sent: Thursday, April 04, 2002 6:05 PM # To: Bob Kopacz # Cc: Tony Johansson; David Spence; aaa-wg # Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] # # Bob Kopacz wrote: # # >However, now that the handoff AMR contains the HA's identity+realm, a # >new AAAH doesn't have this problem. So it seems that the need to employ # >a single AAAH over the life of a session is gone, at least in terms of # >the "mapping HA IP Address to Identity+Realm" snag. # > # Yes. I agree that it in some cases might make things a bit smoother, but # I think this should be optional since the protocol does seem to work # well without it. # # >One thing that a new AAAH doesn't have, however, is the identity+realm # >of the destination AAAF hosting the foreign HA. A single # >session-stateful AAAH employed over the life of a MN's session would # >have this destination-AAAF-identity information as part of his session # >state. If the AAAH needs to know the destination-AAAF's identity for # >the purpose of securing session keys, then this presents a problem for a # >new AAAH. # > # Here you and Tony have dug in way more deeply than I. If all you need is # the identity of the AAAF you should direct your HAR to, wouldn't the # Mip-Originating-Foreign-AAA AVP suffice if you require the AAAF to add # it if a AAAF is present (otherwise the problem obviously doesn't exist)? No. I didn't describe the context fully enough earlier, sorry. In the case I was thinking about, there are two foreign realms involved. The MN first visited realm X, was allocated HA(X), and HA(X) is hosted by AAAF(X). Then the MN migrated to realm Y, and attached to FA(Y), and FA(Y) is hosted by AAAF(Y). The AMR's MIP-Originating-AAAF is AAAF(Y) in the new realm. And the AAAH (maybe) wants to set up some sort of SA with AAAF(X) in the old realm, and the AAAH doesn't know who AAAF(X) is. Question for Tony: Since the AMR now contains the HA's identity, it seems there is less need to require a single AAAH over the life of a MN session, since a new AAAH can contact the HA as easily as a previous AAAH could. So what is the reason for wanting to require a single AAAH over the life of a MN session? Is it to help resolve the above-mentioned securing-session-key problem, where a new AAAH wouldn't know who AAAF(X) is, but an old session-stateful AAAH would? Does that mean that session-statefulness is now also required? Sorry I'm so thick. # >>>2. The AAAH can be assured that the AMR has actually passed through an # >>>AAAF on the way, and thus that the foreign network had its opportunity # >>>to apply its policy. What I mean is this: When the FA sends an AMR, it # >>>is routed by Destination-Realm. Suppose the FA has a Relay between # >>>itself and the local AAAF. The FA sends the AMR to the Relay. If the # >>>Relay's routing is misconfigured, the Relay may just route the AMR # >>>directly to the AAAH, bypassing the AAAF. The AAAH wouldn't necessary # >>>know that the AAAF was bypassed. But if the MIP-Originating-Foreign-AAA # >>>AVP was required but not present, this would tip off the AAAH that # >>>something was amiss. # >> # >>If we agree to say that a AAAF must add it's identity upon processing a # >>message then I have no objections. But if you are saying that a network # >>MUST have a AAAF I disagree. Consequently the AAAH can't know if # >>something is amiss or not. # > # >Are you saying that a visited foreign network could have FAs but no AAAFs? # >I didn't know that. My understanding of the "real world" scenarios is # >frequently more limited than I'd like. # > # Well... "real world" scenarios are so far pretty scarce. But there is # nothing that I know of that requires a AAAF to exist unless you want to # allow allocation of HAs for visitors. This shouldn't be interpreted as # if I don't like AAAFs, but I think that for a significant subset of # deployments the foreign network doesn't have to have one. # # And, as you know I've been lobbying, if not on the wg list, for some # "real world" networks to be built before the standard goes to an RFC but # I guess it wasn't to be. I guess what I was trying to say was: In the Diameter Mobile IPv4 draft, whenever an FA is involved, there is ALWAYS a local AAAF server in the diagrams and the text. There is no mention of the possibility that there may not be a local AAAF for the FA to pass the AMR through, so I was surprised by your comment. If this sort of thing is ok, then maybe the draft should add a sentence or two saying so. # j # From owner-aaa-wg@merit.edu Thu Apr 4 20:05:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14432 for ; Thu, 4 Apr 2002 20:05:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8927B912DD; Thu, 4 Apr 2002 20:04:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D0F5912DE; Thu, 4 Apr 2002 20:04:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A11CB912DD for ; Thu, 4 Apr 2002 20:04:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 825A75DE5F; Thu, 4 Apr 2002 20:04:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id EEE4B5DDBB for ; Thu, 4 Apr 2002 20:04:55 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3514tl09183; Thu, 4 Apr 2002 19:04:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3514tX24445; Thu, 4 Apr 2002 19:04:55 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA14011; Thu, 4 Apr 2002 19:04:54 -0600 (CST) Received: from ericsson.com (busam56.berkeley.us.am.ericsson.se [138.85.159.206]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA25489; Thu, 4 Apr 2002 19:04:53 -0600 (CST) Message-ID: <3CACF785.89BCFA38@ericsson.com> Date: Thu, 04 Apr 2002 17:01:57 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Johan Johansson , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > > In the case I was thinking about, there are two foreign realms involved. > The MN first visited realm X, was allocated HA(X), and HA(X) is hosted by > AAAF(X). Then the MN migrated to realm Y, and attached to FA(Y), and FA(Y) > is hosted by AAAF(Y). The AMR's MIP-Originating-AAAF is AAAF(Y) in the new > realm. And the AAAH (maybe) wants to set up some sort of SA with AAAF(X) > in the old realm, and the AAAH doesn't know who AAAF(X) is. > > Question for Tony: Since the AMR now contains the HA's identity, it seems > there is less need to require a single AAAH over the life of a MN session, > since a new AAAH can contact the HA as easily as a previous AAAH could. So > what is the reason for wanting to require a single AAAH over the life of a > MN session? Is it to help resolve the above-mentioned > securing-session-key problem, where a new AAAH wouldn't know who AAAF(X) > is, but an old session-stateful AAAH would? Correct. > Does that mean that > session-statefulness is now also required? No, the AAAH can be session stateless using some back-ended mechanism, which is beyond the scope of this protocol, to retrieve necessary info. /Tony From owner-aaa-wg@merit.edu Thu Apr 4 23:28:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18674 for ; Thu, 4 Apr 2002 23:28:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D85091224; Thu, 4 Apr 2002 23:28:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBA04912DF; Thu, 4 Apr 2002 23:28:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C01C91224 for ; Thu, 4 Apr 2002 23:28:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 666225DE64; Thu, 4 Apr 2002 23:28:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 7D7485DE5F for ; Thu, 4 Apr 2002 23:28:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g354SL500373 for ; Fri, 5 Apr 2002 07:28:21 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 07:28:03 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 07:28:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Fri, 5 Apr 2002 07:28:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E5EA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHb902wuGhi1BK0RrOnl8107WsHEwAYdjIg From: To: , , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 04:28:06.0215 (UTC) FILETIME=[485A9D70:01C1DC5A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA18674 Hi all, From my current reading of the Accounting State Machine, It looks like the state machine is actually stateless. I mean that an Accounting Server can recieve messages at any time. I think the current discussion is comes from a different perspective (or misunderstanding) of what the accounting server will do. If we consider the accounting server to be stateless, then we may want to clarify it. If we think that it should be stateful, then Marco's text is probably good - however, we will need more text to handle failure cases. So, the question is: should the accounting server be stateful or stateless? John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 04 April, 2002 19:39 > To: Jari Arkko > Cc: Lialiamou Elena (NET-IMN/Helsinki); johanj@ipunplugged.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > > Hi, > > Jari Arkko writes: > > Perhaps this is our way to a compromise. Why don't we state > > the situation about the potential immediate use or just > > storage of the records in the document. For instance: > > > > "Note that the server side state machines requires the > > reception of accounting records and does not place any > > standards requirement on the processing of these records. > > Implementations of Diameter MAY perform checking, ordering, > > correlation, fraud detection, and other tasks based on > these records. > > Both base Diameter AVPs as well as application specific > > AVPs MAY be inspected as a part of these tasks. > > The tasks can happen either immediately after record > > reception or in a post-processing phase. However, as these > > tasks are typically application or even policy dependent, > > they are not standardized by the Diameter specifications." > > I think this text is quite reasonable, and I would even support > removing the state machine entirely and replacing it with this text > and a bit of explanation. The only reason my original proposal had an > "Open" state was because it was a cut-and-paste of what was already > there. However, after reading the discussion on the issue, I don't > think we should place any requirements on the order in which > accounting records arrive at the accounting server, which is what a > state machine would essentially do. State machines define sets of > acceptable event strings, and by definition other strings are not > acceptable. I think the discussion has shown that there is no > reasonable way to react differently to an "unacceptable" string of > events because there may not be any connection to the authorization > state machine. The server might throw away the entire string, but > personally I think it's better to keep it so you can try to > figure out > what happened later. > > -Pete > From owner-aaa-wg@merit.edu Thu Apr 4 23:32:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19192 for ; Thu, 4 Apr 2002 23:32:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA943912E0; Thu, 4 Apr 2002 23:30:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70E78912E1; Thu, 4 Apr 2002 23:30:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2B59912E0 for ; Thu, 4 Apr 2002 23:30:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 979735DE6F; Thu, 4 Apr 2002 23:30:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id DCE4B5DE65 for ; Thu, 4 Apr 2002 23:30:21 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g354UZ500915 for ; Fri, 5 Apr 2002 07:30:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 07:30:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 07:30:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Date: Fri, 5 Apr 2002 07:30:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DC3@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server Thread-Index: AcHb902wuGhi1BK0RrOnl8107WsHEwAYzkBw From: To: , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 04:30:20.0719 (UTC) FILETIME=[98864BF0:01C1DC5A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA19192 Hi All, I've added this text to 8.2, as the last paragraph before the state machines. John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 04 April, 2002 19:39 > To: Jari Arkko > Cc: Lialiamou Elena (NET-IMN/Helsinki); johanj@ipunplugged.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State > Machines into Client vs. Server > > > > Hi, > > Jari Arkko writes: > > Perhaps this is our way to a compromise. Why don't we state > > the situation about the potential immediate use or just > > storage of the records in the document. For instance: > > > > "Note that the server side state machines requires the > > reception of accounting records and does not place any > > standards requirement on the processing of these records. > > Implementations of Diameter MAY perform checking, ordering, > > correlation, fraud detection, and other tasks based on > these records. > > Both base Diameter AVPs as well as application specific > > AVPs MAY be inspected as a part of these tasks. > > The tasks can happen either immediately after record > > reception or in a post-processing phase. However, as these > > tasks are typically application or even policy dependent, > > they are not standardized by the Diameter specifications." > > I think this text is quite reasonable, and I would even support > removing the state machine entirely and replacing it with this text > and a bit of explanation. The only reason my original proposal had an > "Open" state was because it was a cut-and-paste of what was already > there. However, after reading the discussion on the issue, I don't > think we should place any requirements on the order in which > accounting records arrive at the accounting server, which is what a > state machine would essentially do. State machines define sets of > acceptable event strings, and by definition other strings are not > acceptable. I think the discussion has shown that there is no > reasonable way to react differently to an "unacceptable" string of > events because there may not be any connection to the authorization > state machine. The server might throw away the entire string, but > personally I think it's better to keep it so you can try to > figure out > what happened later. > > -Pete > From owner-aaa-wg@merit.edu Thu Apr 4 23:36:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19224 for ; Thu, 4 Apr 2002 23:36:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3567912DF; Thu, 4 Apr 2002 23:36:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92DBA912E1; Thu, 4 Apr 2002 23:36:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CD06912DF for ; Thu, 4 Apr 2002 23:36:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6654E5DE65; Thu, 4 Apr 2002 23:36:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 005565DE4B for ; Thu, 4 Apr 2002 23:36:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g353qwL23182 for ; Thu, 4 Apr 2002 19:52:58 -0800 Date: Thu, 4 Apr 2002 19:52:58 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: For your examination... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A strawman Diameter-10 draft is up at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-10-2.txt Since this is intended to be the draft that will go to WG last call, please examine it carefully to make sure that your issues have been correctly dealt with. Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Fri Apr 5 01:23:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20344 for ; Fri, 5 Apr 2002 01:23:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70023912E1; Fri, 5 Apr 2002 01:22:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43A60912E2; Fri, 5 Apr 2002 01:22:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCB28912E1 for ; Fri, 5 Apr 2002 01:22:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA97B5DDCC; Fri, 5 Apr 2002 01:22:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 136395DD92 for ; Fri, 5 Apr 2002 01:22:49 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g356Ms519383 for ; Fri, 5 Apr 2002 09:22:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 09:22:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 09:22:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [issue]: New generic host identification AVPs Date: Fri, 5 Apr 2002 09:22:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DC8@esebe004.NOE.Nokia.com> Thread-Topic: [issue]: New generic host identification AVPs Thread-Index: AcHbRuavnok5K8bIRC+IpLZR3iSFyABIy0og From: To: , , Cc: X-OriginalArrivalTime: 05 Apr 2002 06:22:39.0607 (UTC) FILETIME=[49370070:01C1DC6A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA20344 Hi Bob, My biggest concern is this: > "6.x Host-IPv4-Address AVP > > "The Host-IPv4-Address AVP (AVP Code TBD) is of type IPAddress and > contains the IPv4 address of a Diameter agent. This AVP is intended to > be a member of a grouped AVP which carries a collection of Diameter > identification information for a Diameter node." I'd prefer to have a version independent Host-IP-Address in the base spec, not a version specific one. John From owner-aaa-wg@merit.edu Fri Apr 5 02:21:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29433 for ; Fri, 5 Apr 2002 02:21:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F558912E4; Fri, 5 Apr 2002 02:21:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5ED3A912E5; Fri, 5 Apr 2002 02:21:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1E0A912E4 for ; Fri, 5 Apr 2002 02:21:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBA415DDAB; Fri, 5 Apr 2002 02:21:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 1D03E5DD92 for ; Fri, 5 Apr 2002 02:21:37 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g357Kmu21976 for ; Fri, 5 Apr 2002 10:20:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 10:21:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 10:21:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue]: New generic host identification AVPs Date: Fri, 5 Apr 2002 10:21:35 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DCE@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue]: New generic host identification AVPs Thread-Index: AcHbsbDQHsq4ba81SHaYXhuzxPWrOgAwKZEg From: To: , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 07:21:35.0793 (UTC) FILETIME=[84F22A10:01C1DC72] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29433 Hi Johan, > As discussed in issue 305 of late there seems to be little if any use > for anything except the IP address of the FA, so it at least seems > reasonable to make the MIP-Foreign-Agent-Host avp contain an IPv4 > address. This will become clearer in the next few days no doubt. I'm not following the status of 305 so closely, so could you more specifically comment on what changes to the Base spec would be needed / desired. John From owner-aaa-wg@merit.edu Fri Apr 5 02:55:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29772 for ; Fri, 5 Apr 2002 02:55:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7EA7912E6; Fri, 5 Apr 2002 02:54:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5953912E7; Fri, 5 Apr 2002 02:54:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93619912E6 for ; Fri, 5 Apr 2002 02:54:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 745B75DDE8; Fri, 5 Apr 2002 02:54:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B17B15DDAB for ; Fri, 5 Apr 2002 02:54:38 -0500 (EST) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g357tn4b012755; Fri, 5 Apr 2002 09:55:50 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" Cc: "Tony Johansson" , "Joe Lau" , "AAA Working Group" Subject: RE: [AAA-WG]: Issue 317:FA-HA Key Date: Fri, 5 Apr 2002 09:52:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sivasundar, >-----Original Message----- >From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] >Sent: den 4 april 2002 18:41 >To: Fredrik Johansson >Cc: Tony Johansson; Joe Lau; AAA Working Group >Subject: RE: [AAA-WG]: Issue 317:FA-HA Key > > > >Hi Fredrick, > > >> >This is different from the two implementations I was referring in my >> >original email: >> > >> >1. The HA implementation maintains only one key to the FA. Everytime >> >it get a new key to the FA, it will refresh the existing key (if any) >> >and assign the same SPI to the new key. This is the only key that will >> >be used for all communication between the FA and HA. (corresponds to >> >"any key") >> >> But this is a illegal behavior, what if the message distributing >the keys to >> the FA gets lost on its way? Consider the case where the HA >receives a new >> key for the FA and refreshes the existing key and assigns the >same SPI (as >> you indicate) to the new key. If the FA does not receive the new >key it will >> try to use the old key which still might be valid since it should request >> new keys sometime before the old one expires. When the request >reaches the >> HA it will check what key to use by looking at the SPI, the HA >will now take >> the new key since it has already replaced the old one, i.e. you get an >> authentication failure just beacause the HA replaced the key for >that SPI. > >true. > >> > >> >2. The FA implementation maintains HA-FA key for each session, which >> >is the one and only key that can be used for any communication between >> >the FA and HA for that session -- the FA will expect the authenticator >> >from the HA to have been created only using that session's key (and >> >SPI). (corresponds to "session key"). >> >> The FA-HA keys does not have anything todo with the session, the session >> might just be the one that distributes the key. A Security Association is >> between a pair of nodes. When the FA should authenticate a mip >msg it looks >> at the SPI to find a Security Context within the Mobility Security >> Association that exists between the FA and the node that sent >the message. >> It may very well be so that every session adds a new Security >Context to the >> Mobility Security Association, but they are all valid for any session >> between these nodes. Each Context may have a lifetime similar to >that of the >> session that added it, but there is nothing in the context that >tells the FA >> which session that added it. > >This IS more in line with base Mobile IP. However, if the FA-HA key >does not have anything to do with the session, then it seems like the >key-lifetime rule wrt termination of session (section 6.13) may not be >applicable to it!! I interpret section 6.13 as follows. You can't use the key after the lifetime has expired (which is reasonable) If the key expires while the session is still active, you must either renew the key or terminate the session. And it's not so strange, if you don't renew the key you will not be able to re-register, thus the session will be terminated. So I can't really see what not applicable with section 6.13. But please tell me if I misunderstood you. /Fredrik > > >Anyway, greatly appreciate your detailed clarification here. > > > >Siva > > From owner-aaa-wg@merit.edu Fri Apr 5 11:56:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09722 for ; Fri, 5 Apr 2002 11:56:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A8AD2912ED; Fri, 5 Apr 2002 11:56:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BE51912EE; Fri, 5 Apr 2002 11:56:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13936912ED for ; Fri, 5 Apr 2002 11:56:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E152A5DE7A; Fri, 5 Apr 2002 11:56:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C92F65DDC4 for ; Fri, 5 Apr 2002 11:56:40 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 89DFF6C; Fri, 5 Apr 2002 11:56:40 -0500 (EST) From: "Bob Kopacz" To: , , Cc: Subject: RE: [AAA-WG]: RE: [issue]: New generic host identification AVPs Date: Fri, 5 Apr 2002 11:55:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DC8@esebe004.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > john.loughney@nokia.com > Sent: Friday, April 05, 2002 1:23 AM > To: BKopacz@InterlinkNetworks.com; tony.johansson@ericsson.com; > DSpence@InterlinkNetworks.com > Cc: aaa-wg@merit.edu > Subject: [AAA-WG]: RE: [issue]: New generic host identification AVPs > > Hi Bob, > > My biggest concern is this: > > > "6.x Host-IPv4-Address AVP > > > > "The Host-IPv4-Address AVP (AVP Code TBD) is of type IPAddress and > > contains the IPv4 address of a Diameter agent. This AVP is intended to > > be a member of a grouped AVP which carries a collection of Diameter > > identification information for a Diameter node." > > I'd prefer to have a version independent Host-IP-Address in the base > spec, not > a version specific one. That's fine with me. I guess the question, besides judging whatever merit these generic member AVPs have, is Tony's question of whether this is "too much" at this late stage. I should've submitted this earlier. > John > Thanks, Bob K. From owner-aaa-wg@merit.edu Fri Apr 5 11:59:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09801 for ; Fri, 5 Apr 2002 11:59:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B249912EE; Fri, 5 Apr 2002 11:59:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0CEC912EF; Fri, 5 Apr 2002 11:59:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1563912EE for ; Fri, 5 Apr 2002 11:59:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0F8B5DE7A; Fri, 5 Apr 2002 11:59:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id AA1A15DDC4 for ; Fri, 5 Apr 2002 11:59:10 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 5E6396C; Fri, 5 Apr 2002 11:59:10 -0500 (EST) From: "Bob Kopacz" To: , Cc: , , Subject: RE: [AAA-WG]: [issue]: New generic host identification AVPs Date: Fri, 5 Apr 2002 11:58:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DCE@esebe004.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John and Johan, As I understand Johan's comment, it would represent a change to the Mobile IPv4 draft, and no change to the Base draft. Bob K. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, April 05, 2002 2:22 AM > To: johanj@ipunplugged.com; BKopacz@interlinknetworks.com > Cc: tony.johansson@ericsson.com; DSpence@interlinknetworks.com; > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: [issue]: New generic host identification AVPs > > > Hi Johan, > > > As discussed in issue 305 of late there seems to be little if any use > > for anything except the IP address of the FA, so it at least seems > > reasonable to make the MIP-Foreign-Agent-Host avp contain an IPv4 > > address. This will become clearer in the next few days no doubt. > > I'm not following the status of 305 so closely, so could you more > specifically comment on what changes to the Base spec would be > needed / desired. > > John > From owner-aaa-wg@merit.edu Fri Apr 5 12:46:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11354 for ; Fri, 5 Apr 2002 12:46:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C2A04912F2; Fri, 5 Apr 2002 12:43:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CE41912F5; Fri, 5 Apr 2002 12:43:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C683912F2 for ; Fri, 5 Apr 2002 12:43:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id F15025DE2B; Fri, 5 Apr 2002 12:43:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id D014B5DD97 for ; Fri, 5 Apr 2002 12:43:26 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 29D19C00664; Fri, 5 Apr 2002 09:43:24 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA10802; Fri, 5 Apr 2002 09:44:10 -0800 (PST) Date: Fri, 5 Apr 2002 09:44:09 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: Tony Johansson , Joe Lau , AAA Working Group Subject: RE: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Fredrick, On Fri, 5 Apr 2002, Fredrik Johansson wrote: > >This IS more in line with base Mobile IP. However, if the FA-HA key > >does not have anything to do with the session, then it seems like the > >key-lifetime rule wrt termination of session (section 6.13) may not be > >applicable to it!! > > I interpret section 6.13 as follows. > You can't use the key after the lifetime has expired (which is reasonable) > If the key expires while the session is still active, you must either renew > the key or terminate the session. And it's not so strange, if you don't > renew the key you will not be able to re-register, thus the session will be > terminated. So I can't really see what not applicable with section 6.13. But > please tell me if I misunderstood you. Ok. From all these discussions, this is how I think the HA-FA was meant to be used/created: 1. Each session can have a HA-FA key but any of them can be used by the FA/HA irrespective of the session (since HA-FA key is NOT session specific) 2. Each HA-FA session key must have a different SPI (to enable proper auth since FA-HA keys from other sessions can be used). 3. When a HA-FA session key is renewed, the new key must be given the same SPI. (This will allow the session termination rule from section 6.13 to apply to the HA-FA key.) If I am correct, then, IMHO, the draft should at least say something about maintaining a unique SPI for each session key and that usage of the HA-FA key is not restricted to that session. thanks, Siva From owner-aaa-wg@merit.edu Fri Apr 5 14:37:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15193 for ; Fri, 5 Apr 2002 14:37:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 192CC9120E; Fri, 5 Apr 2002 14:37:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA88691212; Fri, 5 Apr 2002 14:37:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 919349120E for ; Fri, 5 Apr 2002 14:37:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6AECB5DE0A; Fri, 5 Apr 2002 14:37:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 0113C5DD96 for ; Fri, 5 Apr 2002 14:37:04 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g35Jb4i03572; Fri, 5 Apr 2002 13:37:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g35Jb4a25201; Fri, 5 Apr 2002 13:37:04 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA07731; Fri, 5 Apr 2002 13:37:03 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA14021; Fri, 5 Apr 2002 13:37:02 -0600 (CST) Message-ID: <3CADFC2F.C8560F2A@ericsson.com> Date: Fri, 05 Apr 2002 11:34:07 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Fredrik Johansson , Joe Lau , AAA Working Group Subject: Re: [AAA-WG]: Issue 317:FA-HA Key References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, Sivasundar Ramamurthy wrote: > Hi Fredrick, > > On Fri, 5 Apr 2002, Fredrik Johansson wrote: > > > >This IS more in line with base Mobile IP. However, if the FA-HA key > > >does not have anything to do with the session, then it seems like the > > >key-lifetime rule wrt termination of session (section 6.13) may not be > > >applicable to it!! > > > > I interpret section 6.13 as follows. > > You can't use the key after the lifetime has expired (which is reasonable) > > If the key expires while the session is still active, you must either renew > > the key or terminate the session. And it's not so strange, if you don't > > renew the key you will not be able to re-register, thus the session will be > > terminated. So I can't really see what not applicable with section 6.13. But > > please tell me if I misunderstood you. > > Ok. From all these discussions, this is how I think the HA-FA was > meant to be used/created: > > 1. Each session can have a HA-FA key but any of them can be used by > the FA/HA irrespective of the session (since HA-FA key is NOT session > specific) Right. > > > 2. Each HA-FA session key must have a different SPI (to enable proper > auth since FA-HA keys from other sessions can be used). Right. Section 5.0 - "The SPI values are used as key identifiers, meaning that each session key has its own SPI value; nodes that share a key also share an SPI". > > > 3. When a HA-FA session key is renewed, the new key must be given the > same SPI. (This will allow the session termination rule from section > 6.13 to apply to the HA-FA key.) The HA has the control and responsibility of allocating the FA-HA SPI, section 5.0 - "The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [MIPKEYS], while the Home Agent allocates the Mobile-Foreign, Mobile-Home and Foreign-Home SPIs." > > > If I am correct, then, IMHO, the draft should at least say something > about maintaining a unique SPI for each session key and that usage of > the HA-FA key is not restricted to that session. As pointed out above the HA has the responsiblitity of allocating the SPI, so the HA can make sure that each FA-HA key has its an own SIP value. IMHO, the SIP handling described in section 5.0 and 6.0 in the Diameter MIPv4 appl plus [MIPKEYS] is clear and good enough. /Tony > > > thanks, > > Siva From owner-aaa-wg@merit.edu Fri Apr 5 15:02:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16886 for ; Fri, 5 Apr 2002 15:02:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37F30912F5; Fri, 5 Apr 2002 15:01:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDCA7912F6; Fri, 5 Apr 2002 15:01:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1141912F5 for ; Fri, 5 Apr 2002 15:01:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCAFA5DDEA; Fri, 5 Apr 2002 15:01:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B663C5DD98 for ; Fri, 5 Apr 2002 15:01:26 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 2CE606C; Fri, 5 Apr 2002 15:01:26 -0500 (EST) From: "Bob Kopacz" To: "Johan Johansson" , "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: Need Accounting-Sub-Session-Id for Diameter Mobile IP accounting? Date: Fri, 5 Apr 2002 15:00:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony and Johan, This is a preview of a possible issue. I need to talk this over with one of my cohorts who is more on top of this than I am, but with 16-April looming, I wanted to prime the pump. The Diameter Mobile IPv4 draft talks about accounting, and mentions the Acct-Multi-Session-Id AVP as the key that ties together all of the accounting information for a MN's session, as it undergoes handoffs to various FAs. The draft doesn't mention the (probable) need for the Accounting-Sub-Session-Id AVP, but maybe it should. As I understand things (which may be wrong), here's where the Accounting-Sub-Session-Id would come into play: As the MN is handed off among FAs, each FA generates accounting with a different Session-Id. The HA and all the FAs generate accounting with the same Acct-Multi-Session-Id. But for a given FA, the MN's call may be handed off among various radio nodes, each tied to this one FA. The FA may want to generate the accounting for the activity of each radio node. The FA would do this by treating each RN session as a subsession, and use the Accounting-Sub-Session-Id to identify each RN session (since the Session-Id and Acct-Multi-Session-Id wouldn't be changing). I may not be using the terminology quite correctly, but I hope you get my drift. The 3GPP2 Wireless IP Network Standard document has a means to report accounting for each RN (sub)session, so I am guessing that Diameter Mobile IPv4 accounting wants to support this notion too. Is it also possible that the HA may want to use the Accounting-Sub-Session-Id to report accounting information for each FA handoff? That way, the HA's accounting and each FA's accounting could be correlated. Bob K. From owner-aaa-wg@merit.edu Fri Apr 5 17:24:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02590 for ; Fri, 5 Apr 2002 17:24:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48D9E912F6; Fri, 5 Apr 2002 17:24:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C65E912F7; Fri, 5 Apr 2002 17:24:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 087B2912F6 for ; Fri, 5 Apr 2002 17:24:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7B7F5DDD1; Fri, 5 Apr 2002 17:24:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 941F35DDA9 for ; Fri, 5 Apr 2002 17:24:02 -0500 (EST) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 640F879; Fri, 5 Apr 2002 17:24:02 -0500 (EST) From: "Bob Kopacz" To: "John Loughney" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Minor clarifications/corrections to Base-10-2 Date: Fri, 5 Apr 2002 17:22:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Minor clarifications/corrections to Base-10-2 Submitter name: Bob Kopacz Submitter email address:bkopacz@interlinknetworks.com Date first submitted: 04-05-2002 Reference: Document: draft-base-10-2 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Minor corrections/clarifications to base-10-2. Requested change: - - - - In the Table of Contents 1.1.1 Differences from Radius Capitalize "Radius" - - - - In section 8.1 Authorization Session State Machine Replace the two entries: State Event Action New State ------------------------------------------------------------- Open Home server wants to send ASR Discon terminate the service Discon ASA Received Cleanup Idle With: State Event Action New State ------------------------------------------------------------- Open Home server wants to send ASR Open terminate the service Open ASA Received Cleanup Idle with Result-Code = UNKNOWN-SESSION-ID Open ASA Received None Open with Result-Code (ignore) not = UNKNOWN-SESSION-ID Not ASA Received None No Change. Open This per issue#275, which I think was accepted, but the changes weren't made to the state table. - - - - In section 10.1 Base Protocol Command AVP Table Change: +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 | To: Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1| This per issue#264 (which I think was accepted but the changes weren't made to the occurrence rule table): "Since it is natural and harmless for an implementation to echo back the User-Name, allow but do not require the User-Name AVP to appear in Answer messages, if present in the Request." - - - - In 14.1 Normative References These have expired: [AAATRANS] draft-ietf-aaa-transport-04.txt, June 2001. These are not the latest: [CMS] draft-ietf-aaa-diameter-cms-sec-03.txt - - - - In 14.2 Non-Normative References These are not the latest: [DIAMMIP] draft-ietf-aaa-diameter-mobileip-08.txt [MIPV4] IP Mobility Support. RFC 2002 [NASREQ] draft-ietf-aaa-diameter-nasreq-08.txt - - - - In section 16 Authors' Addresses | Questions about this memo can be directed to: | | Pat R. Calhoun | Black Storm Networks | 250 Cambridge Avenue, Suite 200 | Palo Alto, California, 94306 | USA | | Phone: +1 650-617-2932 | Fax: +1 650-786-6445 | E-mail: pcalhoun@diameter.org I don't think this is Pat's email address (though it's the one he encourages me to use :) - - - - In section 17 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. Should the year be (2002) ? - - - - From owner-aaa-wg@merit.edu Fri Apr 5 17:54:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04885 for ; Fri, 5 Apr 2002 17:54:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EDB891213; Fri, 5 Apr 2002 17:54:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6EF791214; Fri, 5 Apr 2002 17:54:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B871B91213 for ; Fri, 5 Apr 2002 17:54:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EBAF5DDEA; Fri, 5 Apr 2002 17:54:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 800A85DDA9 for ; Fri, 5 Apr 2002 17:54:10 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 28220C006E4; Fri, 5 Apr 2002 14:54:10 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id OAA11393; Fri, 5 Apr 2002 14:54:56 -0800 (PST) Date: Fri, 5 Apr 2002 14:54:55 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: Tony Johansson , Joe Lau , AAA Working Group Subject: RE: [AAA-WG]: Issue 317:FA-HA Key In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Fredrick, I am still trying to figure this out so please bear with me. :-) > > I interpret section 6.13 as follows. > > You can't use the key after the lifetime has expired (which is reasonable) > > If the key expires while the session is still active, you must either renew > > the key or terminate the session. And it's not so strange, if you don't > > renew the key you will not be able to re-register, thus the session will be > > terminated. So I can't really see what not applicable with section 6.13. But > > please tell me if I misunderstood you. But if the FA can use HA-FA keys from other sessions, re-registration on a particular session can succeed even if the HA-FA key for that session expires! So why should the session terminate even when re-registration can succeed? Does that then mean that if the FA requests a FA-HA session key, it must renew it to keep the session alive, even if it does not want to use the key? thanks, Siva From owner-aaa-wg@merit.edu Sat Apr 6 13:21:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13802 for ; Sat, 6 Apr 2002 13:21:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC1E891217; Sat, 6 Apr 2002 13:21:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82535912FF; Sat, 6 Apr 2002 13:21:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BC0691217 for ; Sat, 6 Apr 2002 13:21:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44BF75DE2F; Sat, 6 Apr 2002 13:21:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9DD4C5DDC0 for ; Sat, 6 Apr 2002 13:21:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g36HbiR18410; Sat, 6 Apr 2002 09:37:44 -0800 Date: Sat, 6 Apr 2002 09:37:44 -0800 (PST) From: Bernard Aboba To: Bob Kopacz Cc: John Loughney , aaa-wg Subject: Re: [AAA-WG]: [issue] Minor clarifications/corrections to Base-10-2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #325. On Fri, 5 Apr 2002, Bob Kopacz wrote: > Issue: Minor clarifications/corrections to Base-10-2 > Submitter name: Bob Kopacz > Submitter email address:bkopacz@interlinknetworks.com > Date first submitted: 04-05-2002 > Reference: > Document: draft-base-10-2 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > Minor corrections/clarifications to base-10-2. > > Requested change: > > - - - - > > In the Table of Contents > > 1.1.1 Differences from Radius > > Capitalize "Radius" > > - - - - > > In section 8.1 Authorization Session State Machine > > Replace the two entries: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Discon > terminate the service > > Discon ASA Received Cleanup Idle > > With: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Open > terminate the service > > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID > > Open ASA Received None Open > with Result-Code (ignore) > not = UNKNOWN-SESSION-ID > > Not ASA Received None No Change. > Open > > This per issue#275, which I think was accepted, but the changes > weren't made to the state table. > > - - - - > > In section 10.1 Base Protocol Command AVP Table > > Change: > +-----------------------------------------------+ > | Command-Code | > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 | > > To: > > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1| > > > This per issue#264 (which I think was accepted but the changes weren't > made to the occurrence rule table): "Since it is natural and harmless for > an implementation to echo back the User-Name, allow but do not require the > User-Name AVP to appear in Answer messages, if present in the Request." > > - - - - > > In 14.1 Normative References > > These have expired: > > [AAATRANS] draft-ietf-aaa-transport-04.txt, June 2001. > > These are not the latest: > > [CMS] draft-ietf-aaa-diameter-cms-sec-03.txt > > - - - - > > In 14.2 Non-Normative References > > These are not the latest: > > [DIAMMIP] draft-ietf-aaa-diameter-mobileip-08.txt > > [MIPV4] IP Mobility Support. RFC 2002 > > [NASREQ] draft-ietf-aaa-diameter-nasreq-08.txt > > - - - - > > In section 16 Authors' Addresses > > | Questions about this memo can be directed to: > | > | Pat R. Calhoun > | Black Storm Networks > | 250 Cambridge Avenue, Suite 200 > | Palo Alto, California, 94306 > | USA > | > | Phone: +1 650-617-2932 > | Fax: +1 650-786-6445 > | E-mail: pcalhoun@diameter.org > > I don't think this is Pat's email address (though it's the one > he encourages me to use :) > > - - - - > > In section 17 Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > Should the year be (2002) ? > > - - - - > From owner-aaa-wg@merit.edu Sat Apr 6 16:11:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15569 for ; Sat, 6 Apr 2002 16:11:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89E1891235; Sat, 6 Apr 2002 16:11:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59FFB91239; Sat, 6 Apr 2002 16:11:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61D1891235 for ; Sat, 6 Apr 2002 16:11:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C7315DE1F; Sat, 6 Apr 2002 16:11:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BEEFD5DD8D for ; Sat, 6 Apr 2002 16:11:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g36KSIl27731 for ; Sat, 6 Apr 2002 12:28:18 -0800 Date: Sat, 6 Apr 2002 12:28:18 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: WG last call countdown... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've submitted Transport-06 to the IETF archive. If you'd like to look at it before it shows up there, see: http://www.drizzle.com/~aboba/AAA/draft-ietf-transport-06.txt I am also expecting new versions of the Base and MIP documents to hit the archive sometime next week. Since WG last call on Base, MIP and Transport will commence as soon as new versions of these drafts show up on the IETF archive, now is the best (and probably the last) time to read these documents and comment on them. So if you haven't read the Diameter specs lately, please consider setting some time aside next week to go over the Base, MIP and Transport documents, so that we can make sure that this WG last call is the last one. This is important because, among other things, the 3GPP folks have dependencies on these documents for the "Bundle 2" set of functionality due in May 2002. We are working very hard to meet these deadlines, and to do this, we have to make sure that the documents we put out are "IESG ready". As Randy Bush, our illustrious O&M Area Director has instructed: "Please read the documents with the viewpoint of someone who is very sceptical." From owner-aaa-wg@merit.edu Sat Apr 6 16:12:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15598 for ; Sat, 6 Apr 2002 16:12:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59A6F91239; Sat, 6 Apr 2002 16:12:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BCDC9123A; Sat, 6 Apr 2002 16:12:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39B9591239 for ; Sat, 6 Apr 2002 16:12:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 205255DE1F; Sat, 6 Apr 2002 16:12:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A7B395DD8D for ; Sat, 6 Apr 2002 16:12:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g36KTF927791 for ; Sat, 6 Apr 2002 12:29:15 -0800 Date: Sat, 6 Apr 2002 12:29:15 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: WG last call countdown... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Oops. It's draft-ietf-aaa-transport-06.txt. On Sat, 6 Apr 2002, Bernard Aboba wrote: > I've submitted Transport-06 to the IETF archive. If you'd like to look at > it before it shows up there, see: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-transport-06.txt > > I am also expecting new versions of the Base and MIP documents to hit the > archive sometime next week. > > Since WG last call on Base, MIP and Transport will commence as soon as new > versions of these drafts show up on the IETF archive, now is the best (and > probably the last) time to read these documents and comment on them. > > So if you haven't read the Diameter specs lately, please consider setting > some time aside next week to go over the Base, MIP and Transport > documents, so that we can make sure that this WG last call is the last > one. > > This is important because, among other things, the 3GPP folks have > dependencies on these documents for the "Bundle 2" set of functionality > due in May 2002. We are working very hard to meet these deadlines, and to > do this, we have to make sure that the documents we put out are "IESG > ready". > > As Randy Bush, our illustrious O&M Area Director has instructed: > > "Please read the documents with the viewpoint of someone who is very > sceptical." > > > From owner-aaa-wg@merit.edu Sun Apr 7 05:39:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23925 for ; Sun, 7 Apr 2002 05:39:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 765BA91252; Sun, 7 Apr 2002 05:39:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A56991253; Sun, 7 Apr 2002 05:39:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21A7D91252 for ; Sun, 7 Apr 2002 05:39:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 018945DFF0; Sun, 7 Apr 2002 05:39:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 687475DFEF for ; Sun, 7 Apr 2002 05:39:36 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B6E0C6A905; Sun, 7 Apr 2002 12:39:28 +0300 (EEST) Message-ID: <3CB00628.9070605@kolumbus.fi> Date: Sun, 07 Apr 2002 11:41:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: John Loughney , aaa-wg Subject: Re: [AAA-WG]: [issue] Minor clarifications/corrections to Base-10-2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > In the Table of Contents > > 1.1.1 Differences from Radius > > Capitalize "Radius" Yes. > In section 8.1 Authorization Session State Machine > > Replace the two entries: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Discon > terminate the service > > Discon ASA Received Cleanup Idle > > With: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Open > terminate the service > > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID > > Open ASA Received None Open > with Result-Code (ignore) > not = UNKNOWN-SESSION-ID > > Not ASA Received None No Change. > Open > > This per issue#275, which I think was accepted, but the changes > weren't made to the state table. I agree with 275, but the solution isn't as simple as this. The current state machine doesn't have 'asa received' action on the 'discon' state and your solution doesn't have the ability to resend ASR due to a temporary failure. Let me propose the following: - We still keep the Discon state as an indication in the server on what we wanted to do - Upon receiving a successful ASA, we don't go to Idle but wait for the STR - Upon receiving an ASA with UNKNOWN_SESSION_ID, we go to Idle > In section 10.1 Base Protocol Command AVP Table > > Change: > +-----------------------------------------------+ > | Command-Code | > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 | > > To: > > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1| > > > This per issue#264 (which I think was accepted but the changes weren't > made to the occurrence rule table): "Since it is natural and harmless for > an implementation to echo back the User-Name, allow but do not require the > User-Name AVP to appear in Answer messages, if present in the Request." Yes. > In 14.1 Normative References > > These have expired: > > [AAATRANS] draft-ietf-aaa-transport-04.txt, June 2001. > > These are not the latest: > > [CMS] draft-ietf-aaa-diameter-cms-sec-03.txt Yes. > In 14.2 Non-Normative References > > These are not the latest: > > [DIAMMIP] draft-ietf-aaa-diameter-mobileip-08.txt > > [MIPV4] IP Mobility Support. RFC 2002 > > [NASREQ] draft-ietf-aaa-diameter-nasreq-08.txt Yes. 2002=>3220. > In section 17 Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > Should the year be (2002) ? Yes. Jari From owner-aaa-wg@merit.edu Sun Apr 7 05:50:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24007 for ; Sun, 7 Apr 2002 05:50:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C567191254; Sun, 7 Apr 2002 05:49:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88F9D91304; Sun, 7 Apr 2002 05:49:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AF0B91254 for ; Sun, 7 Apr 2002 05:49:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77B685DFFB; Sun, 7 Apr 2002 05:49:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 30F745DFFC for ; Sun, 7 Apr 2002 05:49:24 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2B9E66A905; Sun, 7 Apr 2002 12:49:22 +0300 (EEST) Message-ID: <3CB0087A.8050902@kolumbus.fi> Date: Sun, 07 Apr 2002 11:51:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Cc: John Loughney Subject: [AAA-WG]: Issues 325 and TBD References: Content-Type: multipart/mixed; boundary="------------080100010209090306040400" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------080100010209090306040400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Issue #325 was a proposed modification to the ASR/ASA handling in the server auth state machine. Issue #TBD is split from #315 and deals with making the server acct machine stateful (idle/open). In my previous mail to the list, I proposed a solution to #325. An attachment to this e-mail has the updated state machine that implements this solution. Please comment. The #TBD issue has also been discussed on the list. After some off-line discussions with the folks who brought this up, I think I now agree that in some cases one does want to make accounting stateful. However, not in all situations. Even if the choice is largely done by applications, I propose that we list the mandatory state machine (stateless) in the base, but also give an optional state machine that can be used and shared by applications that want to keep state. The latter state machine is stricter in the sense that it doesn't accept all 'strings' of accounting requests, but allows state to be kept. So its use is a tradeoff in losing records under network partition conditions and knowing the state. Again, the updated state machine has the modifications and please comment this as well. Diffs to base-10-2 are also attached. Jari --------------080100010209090306040400 Content-Type: text/plain; name="diamstatesnew.txt" Content-Disposition: inline; filename="diamstatesnew.txt" Content-Transfer-Encoding: 7bit 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service-Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send X' means that the Diameter agent is unable to send command X to the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the corresponding Answer command. The event 'X successfully sent' is the complement of 'Failure to send X'. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device Send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on Send STR Discon Access Device Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device Discon ASR Received Send ASA Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup Open Home server wants to Send ASR Discon terminate the service Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Idle home server Open STR Received Send STA, Idle Cleanup Discon Failure to send ASR Wait, Discon resend ASR Discon ASR Received with Result-Code Cleanup Idle = UNKNOWN_SESSION_ID Discon ASR successfully sent and None Discon Result-Code != UNKNOWN_ SESSION_ID Not ASA Received None No Change. Discon Not STR Received Send STA, Idle Open Cleanup The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send serv. Idle request received, and specific successfully processed answer 8.2 Accounting Session State Machine The following state machines MUST be supported for applications that have an accounting portion or that require only accounting services. The first state machine is to be observed by clients. The server side in the accounting state machine depends in some cases on the particular application. The Diameter base protocol defines a default state machine that MUST be followed by accounting servers advertising support for the Relay application identifier and all applications that have not specified other state machines. This is the second state machine in this section described below. The default server side state machine requires the reception of accounting records in any order and at any time, and does not place any standards requirement on the processing of these records. Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications. Applications MAY define requirements on when to accept accounting records based on the used value of Accounting-Realtime-Required AVP, credit limits checks, and so on. However, the Diameter base protocol defines one optional server side state machine that MAY be followed by applications that require keeping track of the session state at the accounting server. Note that such tracking is incompatible with the ability to sustain long duration connectivity problems. Theferore, the use of this state machine is recommended only in applications where the value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence accounting connectivity problems are required to cause the serviced user to be disconnected. Otherwise, records produced by the client may be lost by the server which no longer accepts them after the connectivity is re-established. This state machine is the third state machine in this section. The state machine is supervised by a supervision session timer Ts the which value should be reasonably higher than the Interim_Record_Interval value. Ts MAY be set to two times the value of the Interim_Record_Interval so as to avoid the accounting session in the Diameter server to change to Idle state in case of short transient network failure. Any event not listed in the state machines MUST be considered as an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send' means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. The event 'Failed answer' means that the Diameter client received a non-transient failure notification in the Accounting Answer command. Note that the action 'Disconnect user/dev' MUST have an effect also to the authorization session state table, e.g. cause the STR message to be sent, if the given application has both authentication/authorization and accounting portions. The states PendingS, PendingI, PendingL, PendingE and PendingB stand for pending states to wait for an answer to an accounting request related to a Start, Interim, Stop, Event or buffered record, respectively. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests Send PendingS access accounting start req. Idle Client or device requests Send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE PendingS User service terminated Store PendingS stop record Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req. PendingI Successful accounting interim Open answer received PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev not equal to GRANT_AND_LOSE PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available event record PendingE Failure to send and no buffer Idle space available PendingE Failed accounting event answer Idle received PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingB Failed accounting answer Delete Idle received record PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available stop record PendingL Failure to send and no buffer Idle space available PendingL Failed accounting stop answer Idle received SERVER, STATELESS ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Idle received, and successfully accounting processed. start answer Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Interim record received, Send Idle and successfully processed. accounting answer Idle Accounting stop request Send Idle received, and successfully accounting processed stop answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE SERVER, STATEFUL ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Open received, and successfully accounting processed. start answer, Start Ts Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE Open Interim record received, Send Open and successfully processed. accounting answer, Restart Ts Open Accounting stop request Send Idle received, and successfully accounting processed stop answer, Stop Ts Open Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE, Stop Ts Open Session supervision timer Ts Stop Ts Idle expired --------------080100010209090306040400 Content-Type: text/plain; name="diamstatesnewdiffs.txt" Content-Disposition: inline; filename="diamstatesnewdiffs.txt" Content-Transfer-Encoding: 7bit 145c145,150 < Discon ASR successfully sent Cleanup Idle --- > Discon ASR Received with Result-Code Cleanup Idle > = UNKNOWN_SESSION_ID > > Discon ASR successfully sent and None Discon > Result-Code != UNKNOWN_ > SESSION_ID 194,197c199,241 < For applications that only require accounting services or < applications that have an accounting portion, the following state < machines MUST be supported. The first is to be observed by clients, < the second by servers. --- > The following state machines MUST be supported for applications > that have an accounting portion or that require only accounting > services. The first state machine is to be observed by clients. > > The server side in the accounting state machine depends in some > cases on the particular application. The Diameter base protocol > defines a default state machine that MUST be followed by accounting > servers advertising support for the Relay application identifier > and all applications that have not specified other state > machines. This is the second state machine in this section > described below. > > The default server side state machine requires the reception of > accounting records in any order and at any time, and does not place > any standards requirement on the processing of these records. > Implementations of Diameter MAY perform checking, ordering, > correlation, fraud detection, and other tasks based on these > records. Both base Diameter AVPs as well as application specific > AVPs MAY be inspected as a part of these tasks. The tasks can > happen either immediately after record reception or in a > post-processing phase. However, as these tasks are typically > application or even policy dependent, they are not standardized by > the Diameter specifications. Applications MAY define requirements > on when to accept accounting records based on the used value of > Accounting-Realtime-Required AVP, credit limits checks, and so on. > > However, the Diameter base protocol defines one optional server > side state machine that MAY be followed by applications that > require keeping track of the session state at the accounting > server. Note that such tracking is incompatible with the ability to > sustain long duration connectivity problems. Theferore, the use of > this state machine is recommended only in applications where the > value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, > and hence accounting connectivity problems are required to cause > the serviced user to be disconnected. Otherwise, records produced > by the client may be lost by the server which no longer accepts > them after the connectivity is re-established. This state machine > is the third state machine in this section. The state machine is > supervised by a supervision session timer Ts the which value should > be reasonably higher than the Interim_Record_Interval value. Ts MAY > be set to two times the value of the Interim_Record_Interval so as > to avoid the accounting session in the Diameter server to change to > Idle state in case of short transient network failure. 224d267 < 341c384 < SERVER, ACCOUNTING --- > SERVER, STATELESS ACCOUNTING 368a412,455 > > > SERVER, STATEFUL ACCOUNTING > State Event Action New State > ------------------------------------------------------------- > > Idle Accounting start request Send Open > received, and successfully accounting > processed. start > answer, > Start Ts > > Idle Accounting event request Send Idle > received, and successfully accounting > processed. event > answer > > Idle Accounting request received, Send Idle > no space left to store accounting > records answer, > Result-Code > = OUT_OF_ > SPACE > > Open Interim record received, Send Open > and successfully processed. accounting > answer, > Restart Ts > > Open Accounting stop request Send Idle > received, and successfully accounting > processed stop answer, > Stop Ts > > Open Accounting request received, Send Idle > no space left to store accounting > records answer, > Result-Code > = OUT_OF_ > SPACE, > Stop Ts > > Open Session supervision timer Ts Stop Ts Idle > expired --------------080100010209090306040400-- From owner-aaa-wg@merit.edu Sun Apr 7 06:56:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24944 for ; Sun, 7 Apr 2002 06:56:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2096291301; Sun, 7 Apr 2002 06:56:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E634091302; Sun, 7 Apr 2002 06:56:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C624E91301 for ; Sun, 7 Apr 2002 06:56:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EA395E049; Sun, 7 Apr 2002 06:56:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id CF53B5E048 for ; Sun, 7 Apr 2002 06:56:29 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020407105628.SLZI12824.fep01-svc.swip.net@ipunplugged.com>; Sun, 7 Apr 2002 12:56:28 +0200 Message-ID: <3CB04244.8080901@ipunplugged.com> Date: Sun, 07 Apr 2002 12:57:40 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Bob Kopacz , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: <3CACF785.89BCFA38@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >Bob Kopacz wrote: > >>Question for Tony: Since the AMR now contains the HA's identity, it seems >>there is less need to require a single AAAH over the life of a MN session, >>since a new AAAH can contact the HA as easily as a previous AAAH could. So >>what is the reason for wanting to require a single AAAH over the life of a >>MN session? Is it to help resolve the above-mentioned >>securing-session-key problem, where a new AAAH wouldn't know who AAAF(X) >>is, but an old session-stateful AAAH would? >> > >Correct. > >>Does that mean that >>session-statefulness is now also required? >> > >No, the AAAH can be session stateless using some back-ended mechanism, which is >beyond the scope of this protocol, to retrieve necessary info. > If you mean that it would keep track through mentioned back-ended mechanism what AAAF the mobile node just used for the indicated session then the AAAH is still stateful. Otherwise we might as well write the entire session state to some back-ended mechanism and call the entire protocol stateless. It seems to me that it would make more sense to have the mobile node carry the information that we are really after, i.e. the identity of the AAAF, than to make it carry the identity of a server that it doesn't care about that may be able to hold the information we want. j From owner-aaa-wg@merit.edu Sun Apr 7 07:05:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25070 for ; Sun, 7 Apr 2002 07:05:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB25791302; Sun, 7 Apr 2002 07:05:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EAD791303; Sun, 7 Apr 2002 07:05:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86ECB91302 for ; Sun, 7 Apr 2002 07:05:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 654515E053; Sun, 7 Apr 2002 07:05:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 97F615E052 for ; Sun, 7 Apr 2002 07:05:30 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020407110529.SMPB12824.fep01-svc.swip.net@ipunplugged.com>; Sun, 7 Apr 2002 13:05:29 +0200 Message-ID: <3CB04461.2080102@ipunplugged.com> Date: Sun, 07 Apr 2002 13:06:41 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue]: New generic host identification AVPs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, if you were cc'd on some mail regarding issue 305 that was a mistake. I *did* mean to involve you in some discussion that was relevant to the base draft but I will try to retrace what emails I've sent to who and send you the correct one in the next few days. j Bob Kopacz wrote: >Hi John and Johan, > >As I understand Johan's comment, it would represent a change >to the Mobile IPv4 draft, and no change to the Base draft. > >Bob K. > >>-----Original Message----- >>From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>Sent: Friday, April 05, 2002 2:22 AM >>To: johanj@ipunplugged.com; BKopacz@interlinknetworks.com >>Cc: tony.johansson@ericsson.com; DSpence@interlinknetworks.com; >>aaa-wg@merit.edu >>Subject: RE: [AAA-WG]: [issue]: New generic host identification AVPs >> >> >>Hi Johan, >> >>>As discussed in issue 305 of late there seems to be little if any use >>>for anything except the IP address of the FA, so it at least seems >>>reasonable to make the MIP-Foreign-Agent-Host avp contain an IPv4 >>>address. This will become clearer in the next few days no doubt. >>> >>I'm not following the status of 305 so closely, so could you more >>specifically comment on what changes to the Base spec would be >>needed / desired. >> >>John >> > From owner-aaa-wg@merit.edu Sun Apr 7 07:44:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25425 for ; Sun, 7 Apr 2002 07:44:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8A6F691304; Sun, 7 Apr 2002 07:43:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BC7191305; Sun, 7 Apr 2002 07:43:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41E4E91304 for ; Sun, 7 Apr 2002 07:43:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EAFA5E07D; Sun, 7 Apr 2002 07:43:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 50A8A5E07B for ; Sun, 7 Apr 2002 07:43:47 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020407114346.SPGZ12824.fep01-svc.swip.net@ipunplugged.com>; Sun, 7 Apr 2002 13:43:46 +0200 Message-ID: <3CB04D5A.4030900@ipunplugged.com> Date: Sun, 07 Apr 2002 13:44:58 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Cc: Sivasundar Ramamurthy Subject: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: HA can not know which ip address to store keys on Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: 04-07-2002 Reference: Document: draft-mip-9 Comment type: Technical Priority: S Section: 4.8 This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. If we as stated in section 4.8 simply copy the value of FA-Host from the Origin-Host field of the incoming AMR and then perform a DNS lookup, which in itself is unattractive, we may at best be able to choose a Diameter interface. If we assume that the CoA address in the reg request is the one to use we are choosing the tunneling interface where a raw mobile ip client would have access to the "real" ip address. It seems that raw MobileIP doesn't handle this case deterministically either and thus probably is a source of interopability problems in MobileIP as well. That discussion will be taken with the MobileIP wg. In any case we can solve the problem within Diameter without relying on the resolution within MobileIP by making the foreign agent include the proper ip address in the AMR to be forwarded to the home agent. We should probably also revamp the FA-Host avp to be an FA-Address AVP. Request changes: Change "4.8 MIP-Foreign-Agent-Host AVP The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type DiameterIdentity and contains the identity of the foreign agent. This AVP is copied from the value of the Origin-Host AVP in the AMR." to "4.8 MIP-Foreign-Agent-Address AVP The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MUST be added by the FA to all AMRs it sends and MUST be copied to the HAR sent by the AAAH." We *could* make it optional if we could agree on a reasonable default interface. My best guess for that would be MIP tunneling interface, in which case we could go with "4.8 MIP-Foreign-Agent-Address AVP The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MAY added by the FA to AMRs it sends and if present the AAAH MUST copy it to the HAR it sends. If the AVP is not present the HA MAY assume that the care-of-address of the mobile node should be used for its security association with the FA. If the FA requires co-located mobile nodes to register with it the MIP-Foreign-Agent-Address AVP MUST be added to all AMRs." Of course occurence tables and ABNFs should be updated too. j From owner-aaa-wg@merit.edu Sun Apr 7 08:46:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25956 for ; Sun, 7 Apr 2002 08:46:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B45A91308; Sun, 7 Apr 2002 08:45:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F16DB91309; Sun, 7 Apr 2002 08:45:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3C3B91308 for ; Sun, 7 Apr 2002 08:45:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38C6C5E0C2; Sun, 7 Apr 2002 08:45:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id C60DA5E0BA for ; Sun, 7 Apr 2002 08:45:16 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020407124515.PPJT23157.fep03-svc.swip.net@ipunplugged.com>; Sun, 7 Apr 2002 14:45:15 +0200 Message-ID: <3CB05BC2.4020706@ipunplugged.com> Date: Sun, 07 Apr 2002 14:46:26 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Bob Kopacz , David Spence , aaa-wg Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301] References: <3CACC887.9285EAED@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >Bob and Johan, > >To really try to clarify this. We are in worst case talking about a single point >of failure for a MN's session. However, this is a limitation already imposed >today in the MIP application, which stated - "In the event that the AMR >generated by the FA is for a session that has was previously authorized by the >AAAH, it MUST include the Destination-Host AVP". So, to be very explicit, we are >not introducing any new limitations with this new functionality design to handle >both issue#299 and #301. Regardless, this perceived limitation (single point of >failure for a MN's session) can be overcome by utilizing the fail over mechanisms >described in Base. > >IMHO, since the failover mechanisms are described in the Base there is no need >to discuss them in the MIP application. > It is not entirely true that the limitation is quite as rigid already, but instead of splitting hairs, I assume that the failover mechanism you are referring to is section 8.18 and the Session-Server-Failover AVP set to the value TRY_AGAIN? It seems to fit the bill quite nicely in any case. My main objection however is that this is unneccessary for issue 299 since this has already been independently solved and misses the target for issue 301 unless you also force the AAAH to keep state. What you really are after is the identity of the AAAF used in the previous authentication so make the mobile node store that instead. As long as you don't demand that the AAAH keep state there is really very little you can gain by hitting the same AAAH. Speaking of keeping state, I can't locate any place where we explicitly disallow stateless clients, but section 1.2 states that In the event that the AMR generated by the FA is for a session that has was previously authorized by the AAAH, it MUST include the Destination-Host AVP, with the identity of the AAAH. The AAAH's identity can be retrieved from the Origin-Host AVP in the last AMA received for the session. which seems to require Diameter session state. Section 1.0 discusses statefulness of all other entities so why not clients? j From owner-aaa-wg@merit.edu Sun Apr 7 08:59:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26026 for ; Sun, 7 Apr 2002 08:59:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDEFB91309; Sun, 7 Apr 2002 08:58:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A543A9130A; Sun, 7 Apr 2002 08:58:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 915D691309 for ; Sun, 7 Apr 2002 08:58:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 616825E0C6; Sun, 7 Apr 2002 08:58:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id B77745DF24 for ; Sun, 7 Apr 2002 08:58:52 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020407125850.QCCS25793.fep02-svc.swip.net@ipunplugged.com>; Sun, 7 Apr 2002 14:58:50 +0200 Message-ID: <3CB05EF1.6010805@ipunplugged.com> Date: Sun, 07 Apr 2002 15:00:01 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , aaa-wg Subject: [AAA-WG]: Re: Need Accounting-Sub-Session-Id for Diameter Mobile IP accounting? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >As I understand things (which may be wrong), here's where the >Accounting-Sub-Session-Id would come into play: > >As the MN is handed off among FAs, each FA generates accounting with a >different Session-Id. The HA and all the FAs generate accounting with >the same Acct-Multi-Session-Id. > >But for a given FA, the MN's call may be handed off among various radio >nodes, each tied to this one FA. The FA may want to generate the >accounting for the activity of each radio node. The FA would do this by >treating each RN session as a subsession, and use the >Accounting-Sub-Session-Id to identify each RN session (since the >Session-Id and Acct-Multi-Session-Id wouldn't be changing). > >I may not be using the terminology quite correctly, but I hope you get >my drift. > >The 3GPP2 Wireless IP Network Standard document has a means to >report accounting for each RN (sub)session, so I am guessing that >Diameter Mobile IPv4 accounting wants to support this notion too. > I suppose this would simply amount to making the Accounting-Sub-Session-Id optional in the AMRs for mobile ip accounting since the foreign network needs to implement this anyway. Making it mandatory would force networks for which this notion of "sub-handover" doesn't make sense to send a dummy avp. I have to admit that I can't quite figure out why an operator would want to send it's internal handovers to another operator though, but if they really think they want to do that, who am I do deny them? >Is it also possible that the HA may want to use the >Accounting-Sub-Session-Id to report accounting information for each FA >handoff? That way, the HA's accounting and each FA's accounting could >be correlated. > Well... I agree that this might provide an extra level of correlation. I am probably not the right person to judge its usefulness, but at the very least it seems *harmless*. j From owner-aaa-wg@merit.edu Sun Apr 7 09:33:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26525 for ; Sun, 7 Apr 2002 09:33:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 539F791259; Sun, 7 Apr 2002 09:33:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1355F9130A; Sun, 7 Apr 2002 09:33:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E2D9891259 for ; Sun, 7 Apr 2002 09:33:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C2B645E0E3; Sun, 7 Apr 2002 09:33:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 31B845E0E2 for ; Sun, 7 Apr 2002 09:33:26 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020407133325.PSCQ23157.fep03-svc.swip.net@ipunplugged.com> for ; Sun, 7 Apr 2002 15:33:25 +0200 Message-ID: <3CB0670B.80508@ipunplugged.com> Date: Sun, 07 Apr 2002 15:34:35 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: [AAA-WG]: Message routing and vendor specific applications Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Message routing and vendor specific applications Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: 04-07-2002 Reference: Document: Base Comment type: Technical Priority: S Section: 2.7, 6.1, 6.1.6, 6.10, 9.7.1 Rationale/Explanation of issue: We allow vendor specific applications with their own "namespaces" but we do not perform routing on them. Section 6.1.6 simply states: Diameter request message routing is done via realms. A Diameter message that is able to be proxied MUST include the target realm in the Destination-Realm AVP. The realm MAY be retrieved from the User- Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Diameter agents MAY have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Realm Routing Table table (see section 2.8). On a side note this should probably be section 2.7, but the important part is that nowhere in these paragraphs is per-application routing mentioned, let alone vendor-specific such. The preceding section 6.1 states The Destination-Realm AVP MUST be present if the message is proxiable. Proxiable request messages MUST also contain either an Acct-Application-Id AVP or an Auth-Application-Id AVP. while 9.7.1 happily claims One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it must have an Acct-Application-Id inside. Pretty contradictory if you ask me. Finally, the section 2.7 describing the realm based routing table says - Application Identifier. A route entry can have a different destination based on the Acct-Application-Id for accounting messages) or Auth-Application-Id (for non-accounting messages) of the message. This field MUST be used as a secondary key field in routing table lookups. It seems to me that it would need to use vendor id *and* application id to perform a proper lookup. Requested change: The solution is conceptually simple: make the routing table store vendor id and application id and add text to 6.1.6 to take these into account when routing requests. We now have two ways to identify the application of a request. Either it has a "naked" Acct/Auth-Application-Id *or* it has a grouped Vendor-Specific-Application-Id AVP where the Vendor-Id is non-zero. Granted, the Diameter standard vendor is an important special case but is it important enough to require a two-stage lookup? What do you think? I'll sneak in an editorial side-issue. Shouldn't we change 6.10 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Either the Auth-Application-Id or the Acct- Application-Id AVP MAY be present. Exactly one of the Auth- Application-Id and Acct-Application-Id AVPs MAY be present. to 6.10 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth- Application-Id and Acct-Application-Id AVPs MUST be present. j From owner-aaa-wg@merit.edu Sun Apr 7 12:55:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28486 for ; Sun, 7 Apr 2002 12:55:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D11F391256; Sun, 7 Apr 2002 12:55:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EF5C91257; Sun, 7 Apr 2002 12:55:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CA9C91256 for ; Sun, 7 Apr 2002 12:55:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 607E65DDC6; Sun, 7 Apr 2002 12:55:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id C3B765DDC1 for ; Sun, 7 Apr 2002 12:55:05 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020407165504.QPSH25793.fep02-svc.swip.net@ipunplugged.com> for ; Sun, 7 Apr 2002 18:55:04 +0200 Message-ID: <3CB0964C.3020900@ipunplugged.com> Date: Sun, 07 Apr 2002 18:56:12 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: [AAA-WG]: Suggestion about hierarchical realms a poor one Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Suggestion about hierarchical realms a poor one Submitter name: Johan Johansson Submitter email address:johanj@ipunplugged.com Date first submitted: 04-09-2002 Reference: Document: draft-base-10-2 Comment type: Technical Priority: 1 Section: 6.1 Rationale: The suggestion is that For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers. If intermediate nodes are desired (see Figure 5), the destination node MUST be in a subrealm and routes to that subrealm MUST exist in the routing table on the sending node and all intermediate nodes. Figure 5 shows an example of a hierarchical network that requires the use of subrealms. In such a network, routing must be performed with longest match from right. Figure 5 then goes on to describe a realm abc.com with e.g. a subrealm called eng.abc.com and a relay node in between. It may not be obvious from the draft, but the original example discussed that motivated this text and figure in the first place as within the context of the mobile ip application where there was a home server in the containing realm abc.com and the home agents within the respective subrealms. Assume that there is a user called john.doe@eng.abc.com whose AMR is handled by the server aaah.abc.com. This is a centralized home server that serves the entire realm abc.com and therefore it has a route for abc.com that on longest match from right has a LOCAL_ACTION entry. Unfortunately this will never be selected since it must have a route to eng.abc.com in order to send the HAR to the home agent, which means that the AMR will arrive at a very surprised home agent. Requested change: Given the time constraints my suggestion is to fumble the issue and remove all mention of it from the document. Route configuration and network topology, within the context of the Mobile IP Diameter application at least, is a surprisingly non-intuitive topic. j From owner-aaa-wg@merit.edu Sun Apr 7 19:19:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02165 for ; Sun, 7 Apr 2002 19:19:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC8EA9121B; Sun, 7 Apr 2002 19:19:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82A5491258; Sun, 7 Apr 2002 19:19:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55DD69121B for ; Sun, 7 Apr 2002 19:19:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F4D95DDB0; Sun, 7 Apr 2002 19:19:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id D9B775DD8C for ; Sun, 7 Apr 2002 19:19:26 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Apr 2002 16:19:26 -0700 Message-ID: From: "Pat R. Calhoun" To: "'Johan Johansson'" , aaa-wg Subject: RE: [AAA-WG]: Suggestion about hierarchical realms a poor one Date: Sun, 7 Apr 2002 16:19:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DE8A.A8889120" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DE8A.A8889120 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Assume that there is a user called john.doe@eng.abc.com whose AMR > is handled by the server aaah.abc.com. This is a centralized home > server that serves the entire realm abc.com and therefore it has a > route for abc.com that on longest match from right has a > LOCAL_ACTION entry. Unfortunately this will never be selected > since it must have a route to eng.abc.com in order to send the HAR > to the home agent, which means that the AMR will arrive at a very > surprised home agent. So if this was the case, why would abc.com ever export eng.abc.com outside its own Administrative domain? It would always advertise abc.com to point to aaah.abc.com, which in turn would forward packets to the appropriate server internally. PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPLDT/TN1fXKoxmisEQK8fQCgnLhWiYsDi678+Zbe4InncYzowBkAn3qF SJEwKkg49sT0mCBMYusYpkbX =Ig1z -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1DE8A.A8889120 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Suggestion about hierarchical realms a poor = one

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Assume that there is a user called = john.doe@eng.abc.com whose AMR
> is  handled by the server aaah.abc.com. = This is a centralized home
> server  that serves the entire realm = abc.com and therefore it has a
> route for  abc.com that on longest match = from right has a
> LOCAL_ACTION entry.  Unfortunately this = will never be selected
> since it must have a route to  eng.abc.com = in order to send the HAR
> to the home agent, which means that  the = AMR will arrive at a very
> surprised home agent.

So if this was the case, why would abc.com ever = export eng.abc.com
outside its own
Administrative domain? It would always advertise = abc.com to point to
aaah.abc.com, which in turn would forward packets to = the appropriate
server internally.

PatC







-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPLDT/TN1fXKoxmisEQK8fQCgnLhWiYsDi678+Zbe4InncYzowBkAn3q= F
SJEwKkg49sT0mCBMYusYpkbX
=3DIg1z
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1DE8A.A8889120-- From owner-aaa-wg@merit.edu Mon Apr 8 04:29:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17812 for ; Mon, 8 Apr 2002 04:29:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D6939125D; Mon, 8 Apr 2002 04:29:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2539125E; Mon, 8 Apr 2002 04:29:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6E639125C for ; Mon, 8 Apr 2002 04:29:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86D7C5DE13; Mon, 8 Apr 2002 04:29:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id D3BB55DE05 for ; Mon, 8 Apr 2002 04:29:33 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g388UX4b027841; Mon, 8 Apr 2002 10:30:34 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" Cc: "Tony Johansson" , "Joe Lau" , "AAA Working Group" Subject: RE: [AAA-WG]: Issue 317:FA-HA Key Date: Mon, 8 Apr 2002 10:27:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] >Sent: den 5 april 2002 19:44 >To: Fredrik Johansson >Cc: Tony Johansson; Joe Lau; AAA Working Group >Subject: RE: [AAA-WG]: Issue 317:FA-HA Key > > > >Hi Fredrick, > >On Fri, 5 Apr 2002, Fredrik Johansson wrote: > >> >This IS more in line with base Mobile IP. However, if the FA-HA key >> >does not have anything to do with the session, then it seems like the >> >key-lifetime rule wrt termination of session (section 6.13) may not be >> >applicable to it!! >> >> I interpret section 6.13 as follows. >> You can't use the key after the lifetime has expired (which is >reasonable) >> If the key expires while the session is still active, you must >either renew >> the key or terminate the session. And it's not so strange, if you don't >> renew the key you will not be able to re-register, thus the >session will be >> terminated. So I can't really see what not applicable with >section 6.13. But >> please tell me if I misunderstood you. > >Ok. From all these discussions, this is how I think the HA-FA was >meant to be used/created: > >1. Each session can have a HA-FA key but any of them can be used by >the FA/HA irrespective of the session (since HA-FA key is NOT session >specific) Correct. > >2. Each HA-FA session key must have a different SPI (to enable proper >auth since FA-HA keys from other sessions can be used). > Correct >3. When a HA-FA session key is renewed, the new key must be given the >same SPI. (This will allow the session termination rule from section >6.13 to apply to the HA-FA key.) > No, it must be given a new unique SPI, you can see it as the old key has expired and a new one is distributed to replace it. /Fredrik >If I am correct, then, IMHO, the draft should at least say something >about maintaining a unique SPI for each session key and that usage of >the HA-FA key is not restricted to that session. > > >thanks, > >Siva From owner-aaa-wg@merit.edu Mon Apr 8 04:30:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17830 for ; Mon, 8 Apr 2002 04:30:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DC029125F; Mon, 8 Apr 2002 04:29:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9D449125C; Mon, 8 Apr 2002 04:29:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 220459125D for ; Mon, 8 Apr 2002 04:29:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDC3F5DE05; Mon, 8 Apr 2002 04:29:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id D2C5F5DDE3 for ; Mon, 8 Apr 2002 04:29:33 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g388U24b027825; Mon, 8 Apr 2002 10:30:12 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" Cc: "Tony Johansson" , "Joe Lau" , "AAA Working Group" Subject: RE: [AAA-WG]: Issue 317:FA-HA Key Date: Mon, 8 Apr 2002 10:26:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, >-----Original Message----- >From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] >Sent: den 6 april 2002 00:55 >To: Fredrik Johansson >Cc: Tony Johansson; Joe Lau; AAA Working Group >Subject: RE: [AAA-WG]: Issue 317:FA-HA Key > > > >Hi Fredrick, > >I am still trying to figure this out so please bear with me. :-) No problem, we need to get all issues cleared so we can get the drafts through iesg, so if I can help answer your questions I'm glad to help > >> > I interpret section 6.13 as follows. >> > You can't use the key after the lifetime has expired (which is >reasonable) >> > If the key expires while the session is still active, you must >either renew >> > the key or terminate the session. And it's not so strange, if you don't >> > renew the key you will not be able to re-register, thus the >session will be >> > terminated. So I can't really see what not applicable with >section 6.13. But >> > please tell me if I misunderstood you. > >But if the FA can use HA-FA keys from other sessions, re-registration >on a particular session can succeed even if the HA-FA key for that >session expires! So why should the session terminate even when >re-registration can succeed? > >Does that then mean that if the FA requests a FA-HA session key, it >must renew it to keep the session alive, even if it does not want to >use the key? No, you're right, as long as the FA has one key that it can use it doesn't have to renew the key that it received for that particular session. /Fredrik > > >thanks, > >Siva > From owner-aaa-wg@merit.edu Mon Apr 8 06:46:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19806 for ; Mon, 8 Apr 2002 06:46:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A44FE91263; Mon, 8 Apr 2002 06:45:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C1EF91266; Mon, 8 Apr 2002 06:45:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 477EE91263 for ; Mon, 8 Apr 2002 06:45:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3FA05DDEA; Mon, 8 Apr 2002 06:45:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 8DA715DD9E for ; Mon, 8 Apr 2002 06:45:41 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38Ainu15594 for ; Mon, 8 Apr 2002 13:44:49 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 13:45:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 13:45:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: Issues 325 and TBD Date: Mon, 8 Apr 2002 13:45:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E0F@esebe004.NOE.Nokia.com> Thread-Topic: Issues 325 and TBD Thread-Index: AcHeGYBxwkSkSKhOSIucQ2y7qY3z9QA0P17Q From: To: , X-OriginalArrivalTime: 08 Apr 2002 10:45:39.0511 (UTC) FILETIME=[86028470:01C1DEEA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA19806 Hi Jari, I think that this is a good proposal. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 07 April, 2002 11:51 > To: aaa-wg > Cc: Loughney John (NRC/Helsinki) > Subject: Issues 325 and TBD > > > > Issue #325 was a proposed modification to the ASR/ASA handling in the > server auth state machine. Issue #TBD is split from #315 and > deals with > making the server acct machine stateful (idle/open). > > In my previous mail to the list, I proposed a solution to #325. An > attachment to this e-mail has the updated state machine that > implements > this solution. Please comment. > > The #TBD issue has also been discussed on the list. After > some off-line > discussions with the folks who brought this up, I think I now > agree that > in some cases one does want to make accounting stateful. > However, not in > all situations. Even if the choice is largely done by applications, I > propose that we list the mandatory state machine (stateless) > in the base, > but also give an optional state machine that can be used and > shared by applications > that want to keep state. The latter state machine is stricter > in the sense > that it doesn't accept all 'strings' of accounting requests, > but allows state > to be kept. So its use is a tradeoff in losing records under > network partition > conditions and knowing the state. Again, the updated state > machine has the > modifications and please comment this as well. > > Diffs to base-10-2 are also attached. > > Jari > From owner-aaa-wg@merit.edu Mon Apr 8 06:52:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19865 for ; Mon, 8 Apr 2002 06:52:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D039491205; Mon, 8 Apr 2002 06:52:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A02A891266; Mon, 8 Apr 2002 06:52:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BBD091205 for ; Mon, 8 Apr 2002 06:52:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AE3D5DE05; Mon, 8 Apr 2002 06:52:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 33C6C5DD9E for ; Mon, 8 Apr 2002 06:52:13 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38AqR515480 for ; Mon, 8 Apr 2002 13:52:27 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 13:52:11 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 13:52:11 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 13:52:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issues 325 and TBD Date: Mon, 8 Apr 2002 13:52:10 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF2718421204B@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issues 325 and TBD Thread-Index: AcHeGbTUNV/HURMAR1GJzVfju1uRrwA0SCKQ From: To: , Cc: X-OriginalArrivalTime: 08 Apr 2002 10:52:11.0462 (UTC) FILETIME=[6FA17E60:01C1DEEB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA19865 Hi, I think this new server acc state machine solves those problems which I pointed out last week. So it is OK to me. br, JPK -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 07. April 2002 11:51 To: aaa-wg Cc: Loughney John (NRC/Helsinki) Subject: [AAA-WG]: Issues 325 and TBD Issue #325 was a proposed modification to the ASR/ASA handling in the server auth state machine. Issue #TBD is split from #315 and deals with making the server acct machine stateful (idle/open). In my previous mail to the list, I proposed a solution to #325. An attachment to this e-mail has the updated state machine that implements this solution. Please comment. The #TBD issue has also been discussed on the list. After some off-line discussions with the folks who brought this up, I think I now agree that in some cases one does want to make accounting stateful. However, not in all situations. Even if the choice is largely done by applications, I propose that we list the mandatory state machine (stateless) in the base, but also give an optional state machine that can be used and shared by applications that want to keep state. The latter state machine is stricter in the sense that it doesn't accept all 'strings' of accounting requests, but allows state to be kept. So its use is a tradeoff in losing records under network partition conditions and knowing the state. Again, the updated state machine has the modifications and please comment this as well. Diffs to base-10-2 are also attached. Jari From owner-aaa-wg@merit.edu Mon Apr 8 07:12:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20096 for ; Mon, 8 Apr 2002 07:12:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F84F91266; Mon, 8 Apr 2002 07:12:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B53E91267; Mon, 8 Apr 2002 07:12:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E511691266 for ; Mon, 8 Apr 2002 07:12:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA2045DE22; Mon, 8 Apr 2002 07:12:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 12DBB5DD9E for ; Mon, 8 Apr 2002 07:12:28 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BBXu29185 for ; Mon, 8 Apr 2002 14:11:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 14:12:23 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:12:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issues 325 and TBD Date: Mon, 8 Apr 2002 14:12:22 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3E883@esebe016.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issues 325 and TBD Thread-Index: AcHeGbRhEVTLE9QkSfKC5xdpYnrxwQA1DIvQ From: To: , Cc: X-OriginalArrivalTime: 08 Apr 2002 11:12:23.0023 (UTC) FILETIME=[41C707F0:01C1DEEE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20096 Hi, I think the Jari's proposal make sense and solve the problems I pointed out last week. I fully support this proposal. BR Marco > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 07. April 2002 11:51 > To: aaa-wg > Cc: Loughney John (NRC/Helsinki) > Subject: [AAA-WG]: Issues 325 and TBD > > > > Issue #325 was a proposed modification to the ASR/ASA handling in the > server auth state machine. Issue #TBD is split from #315 and > deals with > making the server acct machine stateful (idle/open). > > In my previous mail to the list, I proposed a solution to #325. An > attachment to this e-mail has the updated state machine that > implements > this solution. Please comment. > > The #TBD issue has also been discussed on the list. After > some off-line > discussions with the folks who brought this up, I think I now > agree that > in some cases one does want to make accounting stateful. > However, not in > all situations. Even if the choice is largely done by applications, I > propose that we list the mandatory state machine (stateless) > in the base, > but also give an optional state machine that can be used and > shared by applications > that want to keep state. The latter state machine is stricter > in the sense > that it doesn't accept all 'strings' of accounting requests, > but allows state > to be kept. So its use is a tradeoff in losing records under > network partition > conditions and knowing the state. Again, the updated state > machine has the > modifications and please comment this as well. > > Diffs to base-10-2 are also attached. > > Jari > From owner-aaa-wg@merit.edu Mon Apr 8 07:17:10 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20192 for ; Mon, 8 Apr 2002 07:17:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C34791267; Mon, 8 Apr 2002 07:16:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6409391268; Mon, 8 Apr 2002 07:16:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39A4B91267 for ; Mon, 8 Apr 2002 07:16:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0893A5DE14; Mon, 8 Apr 2002 07:16:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 467E65DDEA for ; Mon, 8 Apr 2002 07:16:32 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BGk506564 for ; Mon, 8 Apr 2002 14:16:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 14:16:31 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:16:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issues 325 and TBD Date: Mon, 8 Apr 2002 14:16:30 +0300 Message-ID: <93532512B06FC3489824C18037DB3D4B7B75E1@esebe015.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issues 325 and TBD Thread-Index: AcHeGbTUNV/HURMAR1GJzVfju1uRrwA0SCKQAADvD0A= From: To: , , Cc: X-OriginalArrivalTime: 08 Apr 2002 11:16:31.0103 (UTC) FILETIME=[D5A508F0:01C1DEEE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20192 Hi, It is also OK for me and it is quite clearer the difference between stateful and stateless. Regards Elena > -----Original Message----- > From: Koskinen Juha-Pekka (NET/Tampere) > Sent: 08. April 2002 13:52 > To: jari.arkko@kolumbus.fi; aaa-wg@merit.edu > Cc: Loughney John (NRC/Helsinki) > Subject: RE: [AAA-WG]: Issues 325 and TBD > > > Hi, > > I think this new server acc state machine solves those > problems which I pointed out last week. So it is OK to me. > > br, > JPK > > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 07. April 2002 11:51 > To: aaa-wg > Cc: Loughney John (NRC/Helsinki) > Subject: [AAA-WG]: Issues 325 and TBD > > > > Issue #325 was a proposed modification to the ASR/ASA handling in the > server auth state machine. Issue #TBD is split from #315 and > deals with > making the server acct machine stateful (idle/open). > > In my previous mail to the list, I proposed a solution to #325. An > attachment to this e-mail has the updated state machine that > implements > this solution. Please comment. > > The #TBD issue has also been discussed on the list. After > some off-line > discussions with the folks who brought this up, I think I now > agree that > in some cases one does want to make accounting stateful. > However, not in > all situations. Even if the choice is largely done by applications, I > propose that we list the mandatory state machine (stateless) > in the base, > but also give an optional state machine that can be used and > shared by applications > that want to keep state. The latter state machine is stricter > in the sense > that it doesn't accept all 'strings' of accounting requests, > but allows state > to be kept. So its use is a tradeoff in losing records under > network partition > conditions and knowing the state. Again, the updated state > machine has the > modifications and please comment this as well. > > Diffs to base-10-2 are also attached. > > Jari > From owner-aaa-wg@merit.edu Mon Apr 8 07:22:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20255 for ; Mon, 8 Apr 2002 07:22:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 364D491268; Mon, 8 Apr 2002 07:21:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 022AA91269; Mon, 8 Apr 2002 07:21:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3B8891268 for ; Mon, 8 Apr 2002 07:21:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4D7F5DE29; Mon, 8 Apr 2002 07:21:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 096FA5DDEA for ; Mon, 8 Apr 2002 07:21:44 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BLw510350 for ; Mon, 8 Apr 2002 14:21:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 14:21:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:21:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Minor clarifications/corrections to Base-10-2 Date: Mon, 8 Apr 2002 14:21:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D8B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Minor clarifications/corrections to Base-10-2 Thread-Index: AcHc8KT0Z967kwE3T8u7G+4QdjlWUwB/ZqEg From: To: Cc: X-OriginalArrivalTime: 08 Apr 2002 11:21:42.0699 (UTC) FILETIME=[8F5ECFB0:01C1DEEF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20255 Hi Bob, > In the Table of Contents > > 1.1.1 Differences from Radius > > Capitalize "Radius" Got it. > In section 8.1 Authorization Session State Machine > > Replace the two entries: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Discon > terminate the service > > Discon ASA Received Cleanup Idle > > With: > > State Event Action New State > ------------------------------------------------------------- > > Open Home server wants to send ASR Open > terminate the service > > Open ASA Received Cleanup Idle > with Result-Code > = UNKNOWN-SESSION-ID > > Open ASA Received None Open > with Result-Code (ignore) > not = UNKNOWN-SESSION-ID > > Not ASA Received None No Change. > Open > > This per issue#275, which I think was accepted, but the changes > weren't made to the state table. Got it, according to Jari's follow-on mail > In section 10.1 Base Protocol Command AVP Table > > Change: > To: > > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1| > > > This per issue#264 (which I think was accepted but the changes weren't > made to the occurrence rule table): "Since it is natural and harmless for > an implementation to echo back the User-Name, allow but do not require the > User-Name AVP to appear in Answer messages, if present in the Request." Got it. > In 14.1 Normative References > > These have expired: > > [AAATRANS] draft-ietf-aaa-transport-04.txt, June 2001. It is now v05. > These are not the latest: > > [CMS] draft-ietf-aaa-diameter-cms-sec-03.txt Got it. > - - - - > > In 14.2 Non-Normative References > > These are not the latest: > > [DIAMMIP] draft-ietf-aaa-diameter-mobileip-08.txt > > [MIPV4] IP Mobility Support. RFC 2002 > > [NASREQ] draft-ietf-aaa-diameter-nasreq-08.txt Got it. > In section 16 Authors' Addresses > > | Questions about this memo can be directed to: > | > | Pat R. Calhoun > | Black Storm Networks > | 250 Cambridge Avenue, Suite 200 > | Palo Alto, California, 94306 > | USA > | > | Phone: +1 650-617-2932 > | Fax: +1 650-786-6445 > | E-mail: pcalhoun@diameter.org > > I don't think this is Pat's email address (though it's the one > he encourages me to use :) > > - - - - > > In section 17 Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > Should the year be (2002) ? Yup. Thanks Bob, John From owner-aaa-wg@merit.edu Mon Apr 8 07:23:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20289 for ; Mon, 8 Apr 2002 07:23:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E65991269; Mon, 8 Apr 2002 07:22:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 662B69126B; Mon, 8 Apr 2002 07:22:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55DFC91269 for ; Mon, 8 Apr 2002 07:22:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EA215DE29; Mon, 8 Apr 2002 07:22:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 9B38E5DDEA for ; Mon, 8 Apr 2002 07:22:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BNZJ13512 for ; Mon, 8 Apr 2002 14:23:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 14:22:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:22:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: RE: [issue]: New generic host identification AVPs Date: Mon, 8 Apr 2002 14:22:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E12@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: RE: [issue]: New generic host identification AVPs Thread-Index: AcHcwt0FYyt7rRxmTzOxNtMNkT9/rgCLMoFQ From: To: , , Cc: X-OriginalArrivalTime: 08 Apr 2002 11:22:35.0415 (UTC) FILETIME=[AECAA270:01C1DEEF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20289 Bob, What is the damage if this is not done? John > -----Original Message----- > From: ext Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] > Sent: 05 April, 2002 19:56 > To: Loughney John (NRC/Helsinki); tony.johansson@ericsson.com; > DSpence@InterlinkNetworks.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: RE: [issue]: New generic host > identification AVPs > > > Hi John, > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > john.loughney@nokia.com > > Sent: Friday, April 05, 2002 1:23 AM > > To: BKopacz@InterlinkNetworks.com; tony.johansson@ericsson.com; > > DSpence@InterlinkNetworks.com > > Cc: aaa-wg@merit.edu > > Subject: [AAA-WG]: RE: [issue]: New generic host identification AVPs > > > > Hi Bob, > > > > My biggest concern is this: > > > > > "6.x Host-IPv4-Address AVP > > > > > > "The Host-IPv4-Address AVP (AVP Code TBD) is of type > IPAddress and > > > contains the IPv4 address of a Diameter agent. This > AVP is intended to > > > be a member of a grouped AVP which carries a collection > of Diameter > > > identification information for a Diameter node." > > > > I'd prefer to have a version independent Host-IP-Address in > the base > > spec, not > > a version specific one. > > That's fine with me. > > I guess the question, besides judging whatever merit these > generic member AVPs > have, is Tony's question of whether this is "too much" at > this late stage. I > should've submitted this earlier. > > > John > > > > Thanks, > Bob K. > > From owner-aaa-wg@merit.edu Mon Apr 8 07:31:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20402 for ; Mon, 8 Apr 2002 07:31:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE0709126C; Mon, 8 Apr 2002 07:31:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9BE19126D; Mon, 8 Apr 2002 07:31:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 953DF9126C for ; Mon, 8 Apr 2002 07:31:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 742DC5DDCA; Mon, 8 Apr 2002 07:31:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id AF5AB5DD9E for ; Mon, 8 Apr 2002 07:31:40 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BVp518375 for ; Mon, 8 Apr 2002 14:31:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 14:31:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:31:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Message routing and vendor specific applications Date: Mon, 8 Apr 2002 14:31:35 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E14@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Message routing and vendor specific applications Thread-Index: AcHeONaIW/HjNB93SrWsOZiGg9aHBAAuAVqQ From: To: , X-OriginalArrivalTime: 08 Apr 2002 11:31:35.0727 (UTC) FILETIME=[F0D7B3F0:01C1DEF0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20402 Johan, Do you want to supply the text? John > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 07 April, 2002 18:35 > To: aaa-wg > Subject: [AAA-WG]: Message routing and vendor specific applications > > > Issue: Message routing and vendor specific > applications > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: Base > Comment type: Technical > Priority: S > Section: 2.7, 6.1, 6.1.6, 6.10, 9.7.1 > > Rationale/Explanation of issue: > > We allow vendor specific applications with their own > "namespaces" but we > do not perform routing on them. Section 6.1.6 simply states: > > Diameter request message routing is done via realms. A Diameter > message that is able to be proxied MUST include the target realm in > the Destination-Realm AVP. The realm MAY be retrieved from > the User- > Name AVP, which is in the form of a Network Access > Identifier (NAI). > The realm portion of the NAI is inserted in the Destination-Realm > AVP. > > Diameter agents MAY have a list of locally supported > realms, and MAY > have a list of externally supported realms. When a request is > received that includes a realm that is not locally supported, the > message is routed to the peer configured in the Realm Routing Table > table (see section 2.8). > > On a side note this should probably be section 2.7, but the important > part is that nowhere in these paragraphs is per-application routing > mentioned, let alone vendor-specific such. > > The preceding section 6.1 states > > The Destination-Realm AVP MUST be present if the message is > proxiable. Proxiable request messages MUST also contain either an > Acct-Application-Id AVP or an Auth-Application-Id AVP. > > while 9.7.1 happily claims > > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id > grouped AVP is > present, it must have an Acct-Application-Id inside. > > Pretty contradictory if you ask me. > > Finally, the section 2.7 describing the realm based routing table says > > > - Application Identifier. A route entry can have a different > destination based on the Acct-Application-Id for accounting > messages) or Auth-Application-Id (for non-accounting messages) > of the message. This field MUST be used as a > secondary key field > in routing table lookups. > > It seems to me that it would need to use vendor id *and* > application id > to perform a proper lookup. > > Requested change: > > The solution is conceptually simple: make the routing table > store vendor > id and application id and add text to 6.1.6 to take these > into account > when routing requests. > > We now have two ways to identify the application of a > request. Either it > has a "naked" Acct/Auth-Application-Id *or* it has a grouped > Vendor-Specific-Application-Id AVP where the Vendor-Id is non-zero. > Granted, the Diameter standard vendor is an important special > case but > is it important enough to require a two-stage lookup? > > What do you think? > > I'll sneak in an editorial side-issue. Shouldn't we change > > > 6.10 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Either the Auth-Application-Id or the Acct- > Application-Id AVP MAY be present. Exactly one of the Auth- > Application-Id and Acct-Application-Id AVPs MAY be present. > > to > > 6.10 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth- > Application-Id and Acct-Application-Id AVPs MUST be present. > > j > > From owner-aaa-wg@merit.edu Mon Apr 8 07:39:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20513 for ; Mon, 8 Apr 2002 07:39:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02E629126D; Mon, 8 Apr 2002 07:39:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C219F9126E; Mon, 8 Apr 2002 07:39:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5E5C9126D for ; Mon, 8 Apr 2002 07:39:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FBC65DE22; Mon, 8 Apr 2002 07:39:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id F0E5B5DD8E for ; Mon, 8 Apr 2002 07:39:09 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020408113908.TCRH25793.fep02-svc.swip.net@ipunplugged.com>; Mon, 8 Apr 2002 13:39:08 +0200 Message-ID: <3CB19DC4.3050000@ipunplugged.com> Date: Mon, 08 Apr 2002 13:40:20 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg Subject: Re: [AAA-WG]: Message routing and vendor specific applications References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E14@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sure. I just want to get the issue reviewed first to make sure I am not seeing a problem where there is none and then I'd want to see some reaction to the solution alternatives I have suggested. j john.loughney@nokia.com wrote: >Johan, > >Do you want to supply the text? > > >John > >>-----Original Message----- >>From: ext Johan Johansson [mailto:johanj@ipunplugged.com] >>Sent: 07 April, 2002 18:35 >>To: aaa-wg >>Subject: [AAA-WG]: Message routing and vendor specific applications >> >> >>Issue: Message routing and vendor specific >>applications >>Submitter name: Johan Johansson >>Submitter email address: johanj@ipunplugged.com >>Date first submitted: 04-07-2002 >>Reference: >>Document: Base >>Comment type: Technical >>Priority: S >>Section: 2.7, 6.1, 6.1.6, 6.10, 9.7.1 >> >>Rationale/Explanation of issue: >> >>We allow vendor specific applications with their own >>"namespaces" but we >>do not perform routing on them. Section 6.1.6 simply states: >> >>Diameter request message routing is done via realms. A Diameter >> message that is able to be proxied MUST include the target realm in >> the Destination-Realm AVP. The realm MAY be retrieved from >>the User- >> Name AVP, which is in the form of a Network Access >>Identifier (NAI). >> The realm portion of the NAI is inserted in the Destination-Realm >> AVP. >> >> Diameter agents MAY have a list of locally supported >>realms, and MAY >> have a list of externally supported realms. When a request is >> received that includes a realm that is not locally supported, the >> message is routed to the peer configured in the Realm Routing Table >> table (see section 2.8). >> >>On a side note this should probably be section 2.7, but the important >>part is that nowhere in these paragraphs is per-application routing >>mentioned, let alone vendor-specific such. >> >>The preceding section 6.1 states >> >>The Destination-Realm AVP MUST be present if the message is >> proxiable. Proxiable request messages MUST also contain either an >> Acct-Application-Id AVP or an Auth-Application-Id AVP. >> >>while 9.7.1 happily claims >> >> One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs >> MUST be present. If the Vendor-Specific-Application-Id >>grouped AVP is >> present, it must have an Acct-Application-Id inside. >> >>Pretty contradictory if you ask me. >> >>Finally, the section 2.7 describing the realm based routing table says >> >> >> - Application Identifier. A route entry can have a different >> destination based on the Acct-Application-Id for accounting >> messages) or Auth-Application-Id (for non-accounting messages) >> of the message. This field MUST be used as a >>secondary key field >> in routing table lookups. >> >>It seems to me that it would need to use vendor id *and* >>application id >>to perform a proper lookup. >> >>Requested change: >> >>The solution is conceptually simple: make the routing table >>store vendor >>id and application id and add text to 6.1.6 to take these >>into account >>when routing requests. >> >>We now have two ways to identify the application of a >>request. Either it >>has a "naked" Acct/Auth-Application-Id *or* it has a grouped >>Vendor-Specific-Application-Id AVP where the Vendor-Id is non-zero. >>Granted, the Diameter standard vendor is an important special >>case but >>is it important enough to require a two-stage lookup? >> >>What do you think? >> >>I'll sneak in an editorial side-issue. Shouldn't we change >> >> >>6.10 Vendor-Specific-Application-Id AVP >> >> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >> Grouped and is used to advertise support of a vendor-specific >> Diameter Application. Either the Auth-Application-Id or the Acct- >> Application-Id AVP MAY be present. Exactly one of the Auth- >> Application-Id and Acct-Application-Id AVPs MAY be present. >> >>to >> >>6.10 Vendor-Specific-Application-Id AVP >> >> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >> Grouped and is used to advertise support of a vendor-specific >> Diameter Application. Exactly one of the Auth- >> Application-Id and Acct-Application-Id AVPs MUST be present. >> >>j >> >> > From owner-aaa-wg@merit.edu Mon Apr 8 07:48:51 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20619 for ; Mon, 8 Apr 2002 07:48:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 241609126F; Mon, 8 Apr 2002 07:48:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7D1E91270; Mon, 8 Apr 2002 07:48:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B88C19126F for ; Mon, 8 Apr 2002 07:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96BD85DD8E; Mon, 8 Apr 2002 07:47:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 9FC0B5DD9E for ; Mon, 8 Apr 2002 07:47:51 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38BmoJ26082 for ; Mon, 8 Apr 2002 14:48:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Apr 2002 14:47:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:47:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #325 Minor clarifications/corrects to Base-10/2 - Closed Date: Mon, 8 Apr 2002 14:47:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E17@esebe004.NOE.Nokia.com> Thread-Topic: Issue #325 Minor clarifications/corrects to Base-10/2 - Closed Thread-Index: AcHe8zKhcv+JfCLGR16YVRClce45mQ== From: To: X-OriginalArrivalTime: 08 Apr 2002 11:47:50.0570 (UTC) FILETIME=[35E4F0A0:01C1DEF3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20619 Hi all, Issue #325 Minor clarifications/corrects to Base-10/2 is now closed, changes have been made. John From owner-aaa-wg@merit.edu Mon Apr 8 07:49:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20635 for ; Mon, 8 Apr 2002 07:49:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A763691270; Mon, 8 Apr 2002 07:48:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3442991273; Mon, 8 Apr 2002 07:48:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93D5B9126E for ; Mon, 8 Apr 2002 07:48:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FF0F5DE05; Mon, 8 Apr 2002 07:48:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B6FDC5DE31 for ; Mon, 8 Apr 2002 07:48:37 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38Bmq501868 for ; Mon, 8 Apr 2002 14:48:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Apr 2002 14:48:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:48:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #324 New generic host identification AVPs - possible reject Date: Mon, 8 Apr 2002 14:48:36 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E18@esebe004.NOE.Nokia.com> Thread-Topic: Issue #324 New generic host identification AVPs - possible reject Thread-Index: AcHe80+uJeKboBaHQcu7fUAlFqgR/Q== From: To: X-OriginalArrivalTime: 08 Apr 2002 11:48:36.0463 (UTC) FILETIME=[513FA7F0:01C1DEF3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20635 Hi all, Issue #324 New generic host identification AVPs is now marked as a possible reject. Please comment one way or another. John From owner-aaa-wg@merit.edu Mon Apr 8 07:49:02 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20647 for ; Mon, 8 Apr 2002 07:49:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56CE991271; Mon, 8 Apr 2002 07:48:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 130689126E; Mon, 8 Apr 2002 07:48:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86D149126E for ; Mon, 8 Apr 2002 07:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 609535DE05; Mon, 8 Apr 2002 07:47:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 750375DD8E for ; Mon, 8 Apr 2002 07:47:51 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38Bm6501204 for ; Mon, 8 Apr 2002 14:48:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Apr 2002 14:47:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 14:47:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #321 In progress Normative references to CMS - closed Date: Mon, 8 Apr 2002 14:47:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E16@esebe004.NOE.Nokia.com> Thread-Topic: Issue #321 In progress Normative references to CMS - closed Thread-Index: AcHe8xq7ntj73xBQQLeNod/WZQMlYg== From: To: X-OriginalArrivalTime: 08 Apr 2002 11:47:50.0351 (UTC) FILETIME=[35C385F0:01C1DEF3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20647 Hi all, References to CMS are made non-normative now. John From owner-aaa-wg@merit.edu Mon Apr 8 15:10:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03211 for ; Mon, 8 Apr 2002 15:10:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC47991286; Mon, 8 Apr 2002 15:10:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC0E291287; Mon, 8 Apr 2002 15:10:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 713E091286 for ; Mon, 8 Apr 2002 15:10:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 557B35DF0B; Mon, 8 Apr 2002 15:10:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id F41EF5DDB2 for ; Mon, 8 Apr 2002 15:10:36 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g38JAYl29069; Mon, 8 Apr 2002 14:10:34 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g38JAXN21308; Mon, 8 Apr 2002 14:10:33 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA02373; Mon, 8 Apr 2002 14:10:33 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA07437; Mon, 8 Apr 2002 14:10:32 -0500 (CDT) Message-ID: <3CB1EA76.8A0B6489@ericsson.com> Date: Mon, 08 Apr 2002 12:07:34 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg Cc: Johan Johansson Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA References: <3CB04D5A.4030900@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit So, what do others think about this one? Comments are really appreciated. /Tony Johan Johansson wrote: > Issue: HA can not know which ip address to store keys on > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: draft-mip-9 > Comment type: Technical > Priority: S > Section: 4.8 > > This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. > > The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. > > If we as stated in section 4.8 simply copy the value of FA-Host from the Origin-Host field of the incoming AMR and then perform a DNS lookup, which in itself is unattractive, we may at best be able to choose a Diameter interface. If we assume that the CoA address in the reg request is the one to use we are choosing the tunneling interface where a raw mobile ip client would have access to the "real" ip address. > > It seems that raw MobileIP doesn't handle this case deterministically either and thus probably is a source of interopability problems in MobileIP as well. That discussion will be taken with the MobileIP wg. > > In any case we can solve the problem within Diameter without relying on the resolution within MobileIP by making the foreign agent include the proper ip address in the AMR to be forwarded to the home agent. We should probably also revamp the FA-Host avp to be an FA-Address AVP. > > Request changes: > > Change > > "4.8 MIP-Foreign-Agent-Host AVP > > The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type > DiameterIdentity and contains the identity of the foreign agent. This > AVP is copied from the value of the Origin-Host AVP in the AMR." > > to > > "4.8 MIP-Foreign-Agent-Address AVP > > The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type > IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MUST be added by the FA to all AMRs it sends and MUST be copied to the HAR sent by the AAAH." > > We *could* make it optional if we could agree on a reasonable default interface. My best guess for that would be MIP tunneling interface, in which case we could go with > > "4.8 MIP-Foreign-Agent-Address AVP > > The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type > IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MAY added by the FA to AMRs it sends and if present the AAAH MUST copy it to the HAR it sends. If the AVP is not present the HA MAY assume that the care-of-address of the mobile node should be used for its security association with the FA. If the FA requires co-located mobile nodes to register with it the MIP-Foreign-Agent-Address AVP MUST be added to all AMRs." > > Of course occurence tables and ABNFs should be updated too. > > j From owner-aaa-wg@merit.edu Mon Apr 8 16:13:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04918 for ; Mon, 8 Apr 2002 16:13:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0046E91291; Mon, 8 Apr 2002 16:12:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C022391293; Mon, 8 Apr 2002 16:12:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1FAF91291 for ; Mon, 8 Apr 2002 16:12:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FA495DF43; Mon, 8 Apr 2002 16:12:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 2C9925DF36 for ; Mon, 8 Apr 2002 16:12:47 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g38KCaR00090; Mon, 8 Apr 2002 16:12:36 -0400 (EDT) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA04290; Mon, 8 Apr 2002 15:12:35 -0500 (CDT) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g38KCYa27148; Mon, 8 Apr 2002 15:12:34 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15537.63922.789900.297955@nwsgpc.ih.lucent.com> Date: Mon, 8 Apr 2002 15:12:34 -0500 (CDT) From: Pete McCann To: Jari Arkko Cc: aaa-wg , John Loughney Subject: [AAA-WG]: Issues 325 and TBD In-Reply-To: <3CB0087A.8050902@kolumbus.fi> References: <3CB0087A.8050902@kolumbus.fi> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I hadn't read issue 275 before suggesting changes to the ASR/ASA handling; I think I understand it better now. But a couple of suggestions: Jari Arkko writes: > > Open Home server wants to Send ASR Discon > terminate the service ... > Open STR Received Send STA, Idle > Cleanup > > Discon Failure to send ASR Wait, Discon > resend ASR > > Discon ASR Received with Result-Code Cleanup Idle > = UNKNOWN_SESSION_ID Should be "ASA Received...", right? > Discon ASR successfully sent and None Discon > Result-Code != UNKNOWN_ > SESSION_ID Again, it's the ASA that has the Result-Code. Maybe both of these should be re-worded, "ASR successfully sent, ASA received with Result-Code =/!= ..." > Not ASA Received None No Change. > Discon > > Not STR Received Send STA, Idle > Open Cleanup This last transition has the same action and target state as when STR is received when Open (see above). Can we combine them, i.e., the following: Any STR Received Send STA, Idle Cleanup -Pete From owner-aaa-wg@merit.edu Mon Apr 8 22:19:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14548 for ; Mon, 8 Apr 2002 22:19:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27AE89130D; Mon, 8 Apr 2002 22:19:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E74379130F; Mon, 8 Apr 2002 22:19:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83DB09130D for ; Mon, 8 Apr 2002 22:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 564A35DFEA; Mon, 8 Apr 2002 22:19:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9E8E55DDD3 for ; Mon, 8 Apr 2002 22:19:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g391ZgX10924 for ; Mon, 8 Apr 2002 18:35:42 -0700 Date: Mon, 8 Apr 2002 18:35:41 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue 300] Proposed resolution Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I have come up with the following text for RFC2869bis, and would like to propose an equivalent solution for Diameter in resolution to Issue #300. Comments welcome. 2.5. Usage guidelines 2.5.1. Conflicting messages In some cases, the authentication result implied by the encapsulated EAP packet may not match the result communicated in the RADIUS message. For example, and EAP Failure packet may be encapsulated within an Access- Accept message and an EAP Success packet may be encapsulated within an Access-Reject. Alternatively, no EAP-Message attribute may be included within an Access-Accept or Access-Reject. Such combinations are likely to cause confusion, because the NAS and Peer will arrive at different conclusions as to the outcome of the authentication. For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the Peer. However, on receiving the Success, the Peer will be lead to believe that it authenticated successfully. Similarly, if the NAS receives an Access- Accept with an encapsulated EAP Failure, it will grant access to the Peer. However, on receiving a Failure, the Peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the Peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access. As described in [RFC2284bis], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore no further Access-Requests will be sent to the RADIUS server. As a result, the NAS will not be given an indication of whether to Allow or Deny access while the Peer will be informed as to the outcome of the authentication. To avoid these conflicts, the RADIUS server SHOULD check to make sure that the results implied by an encapsulated EAP-Message attribute and the RADIUS message are in agreement. The following combinations SHOULD NOT be sent by a RADIUS server as part of an EAP conversation: Access-Accept/EAP-Message/EAP-Failure Access-Accept/no EAP-Message attribute Access-Reject/EAP-Message/EAP-Success Access-Reject/no EAP-Message attribute Access-Challenge/EAP-Message/EAP-Success Access-Challenge/EAP-Message/EAP-Failure Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. 2.5.2. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last. 2.5.3. Displayable messages The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284bis]. However, when sent during an EAP conversation, displayable messages SHOULD be encapsulated within an EAP-Message/Notification-Request rather than within a Reply-Message attribute. While a NAS receiving a Reply-Message attribute MAY send an EAP Notification-Request to the peer, several issues may arise from this: [1] Unexpected Notification-Responses. On receiving an EAP Notification-Request, the EAP Peer will send a Notification- Response, and the NAS will pass this on to the RADIUS server, encapsulated within an EAP-Message attribute. Since the RADIUS server may not be expecting a Notification-Response, it may silently discard the packet. [2] Identifier conflicts. While the Notification-Request contains an an Identifier, a Reply-Message attribute does not. As a result, a NAS receiving a Reply-Message and wishing to translate it to a Notification-Request will need to make up an Identifier. Since the NAS cannot make assumptions about how the RADIUS server chooses Identifiers, it is possible that the chosen Identifier will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. As noted in [RFC2284bis] this would violate the requirement that Identifier values be unique within an EAP conversation. 2.5.4. Multiple EAP-Message attributes An Access-Challenge, Access-Accept, Access-Reject or Access-Request message MAY contain zero or more EAP-Message attributes. However, where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to to form a single EAP packet. Since EAP is a "lockstep" protocol, a new EAP-Request cannot be sent until an EAP-Response is received to an outstanding request and only a single Request can be outstanding at a given time. As a result, multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request message. In addition, since a Reply-Message attribute MAY be translated to a Notification-Request by some NASes, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. From owner-aaa-wg@merit.edu Mon Apr 8 23:54:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17104 for ; Mon, 8 Apr 2002 23:54:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1754991290; Mon, 8 Apr 2002 23:53:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAFA591292; Mon, 8 Apr 2002 23:53:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB0AC91290 for ; Mon, 8 Apr 2002 23:53:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF4795DDDD; Mon, 8 Apr 2002 23:53:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A82185DD9C for ; Mon, 8 Apr 2002 23:53:52 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D06506A901; Tue, 9 Apr 2002 06:53:44 +0300 (EEST) Message-ID: <3CB25822.8040508@kolumbus.fi> Date: Tue, 09 Apr 2002 05:55:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete McCann Cc: aaa-wg , John Loughney Subject: Re: [AAA-WG]: Issues 325 and TBD References: <3CB0087A.8050902@kolumbus.fi> <15537.63922.789900.297955@nwsgpc.ih.lucent.com> Content-Type: multipart/mixed; boundary="------------030509060700090200060006" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------030509060700090200060006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pete McCann wrote: > > Discon ASR Received with Result-Code Cleanup Idle > > = UNKNOWN_SESSION_ID > > Should be "ASA Received...", right? Yes. > > Discon ASR successfully sent and None Discon > > Result-Code != UNKNOWN_ > > SESSION_ID > > Again, it's the ASA that has the Result-Code. Maybe both of these > should be re-worded, "ASR successfully sent, ASA received with > Result-Code =/!= ..." Yes. > > Not ASA Received None No Change. > > Discon > > > > Not STR Received Send STA, Idle > > Open Cleanup > > This last transition has the same action and target state as when STR > is received when Open (see above). Can we combine them, i.e., the > following: > > Any STR Received Send STA, Idle > Cleanup Yes. Latest state machine attached, with diff to the previous one I sent on Sunday. Jari --------------030509060700090200060006 Content-Type: text/plain; name="diamstatesstillnew.txt" Content-Disposition: inline; filename="diamstatesstillnew.txt" Content-Transfer-Encoding: 7bit 8.1 Authorization Session State Machine This section contains a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term Service-Specific below refers to a message defined in a Diameter application (e.g. Mobile IP, NASREQ). There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send X' means that the Diameter agent is unable to send command X to the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the corresponding Answer command. The event 'X successfully sent' is the complement of 'Failure to send X'. The following state machine is observed by a client when state is maintained on the server: CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID Pending Successful Service-specific Grant Open authorization answer Access received with default Auth-Session-State value Pending Successful Service-specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-specific authorization answer Pending Failed Service-specific Cleanup Idle authorization answer received Open user or client device Send Open requests access to service service specific auth req Open Successful Service-specific Extend Open authorization answer received Answer Open Failed Service-specific Discon. Idle authorization answer user/device received. Open Session-Timeout Expires on Send STR Discon Access Device Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != SUCCESS Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device Discon ASR Received Send ASA Discon Discon STA Received Discon. Idle user/device The following state machine is observed by a server when it is maintaining state for the session: SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and successful user is authorized serv. specific answer Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup Open Home server wants to Send ASR Discon terminate the service Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Idle home server Discon Failure to send ASR Wait, Discon resend ASR Discon ASR successfully sent and Cleanup Idle ASA Received with Result-Code = UNKNOWN_SESSION_ID Discon ASR successfully sent and None Discon ASA received with Result-Code != UNKNOWN_SESSION_ID Not ASA Received None No Change. Discon Any STR Received Send STA, Idle Cleanup The following state machine is observed by a client when state is not maintained on the server: CLIENT, STATELESS State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req Pending Successful Service-specific Grant Open authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Pending Failed Service-specific Cleanup Idle authorization answer received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device The following state machine is observed by a server when it is not maintaining state for the session: SERVER, STATELESS State Event Action New State ------------------------------------------------------------- Idle Service-specific authorization Send serv. Idle request received, and specific successfully processed answer 8.2 Accounting Session State Machine The following state machines MUST be supported for applications that have an accounting portion or that require only accounting services. The first state machine is to be observed by clients. The server side in the accounting state machine depends in some cases on the particular application. The Diameter base protocol defines a default state machine that MUST be followed by accounting servers advertising support for the Relay application identifier and all applications that have not specified other state machines. This is the second state machine in this section described below. The default server side state machine requires the reception of accounting records in any order and at any time, and does not place any standards requirement on the processing of these records. Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications. Applications MAY define requirements on when to accept accounting records based on the used value of Accounting-Realtime-Required AVP, credit limits checks, and so on. However, the Diameter base protocol defines one optional server side state machine that MAY be followed by applications that require keeping track of the session state at the accounting server. Note that such tracking is incompatible with the ability to sustain long duration connectivity problems. Theferore, the use of this state machine is recommended only in applications where the value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence accounting connectivity problems are required to cause the serviced user to be disconnected. Otherwise, records produced by the client may be lost by the server which no longer accepts them after the connectivity is re-established. This state machine is the third state machine in this section. The state machine is supervised by a supervision session timer Ts the which value should be reasonably higher than the Interim_Record_Interval value. Ts MAY be set to two times the value of the Interim_Record_Interval so as to avoid the accounting session in the Diameter server to change to Idle state in case of short transient network failure. Any event not listed in the state machines MUST be considered as an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send' means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. The event 'Failed answer' means that the Diameter client received a non-transient failure notification in the Accounting Answer command. Note that the action 'Disconnect user/dev' MUST have an effect also to the authorization session state table, e.g. cause the STR message to be sent, if the given application has both authentication/authorization and accounting portions. The states PendingS, PendingI, PendingL, PendingE and PendingB stand for pending states to wait for an answer to an accounting request related to a Start, Interim, Stop, Event or buffered record, respectively. CLIENT, ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Client or device requests Send PendingS access accounting start req. Idle Client or device requests Send PendingE a one-time service accounting event req Idle Records in storage Send PendingB record PendingS Successful accounting Open start answer received PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE PendingS User service terminated Store PendingS stop record Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req. PendingI Successful accounting interim Open answer received PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev not equal to GRANT_AND_LOSE PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received PendingE Failure to send and buffer Store Idle space available event record PendingE Failure to send and no buffer Idle space available PendingE Failed accounting event answer Idle received PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle PendingB Failed accounting answer Delete Idle received record PendingL Successful accounting Idle stop answer received PendingL Failure to send and buffer Store Idle space available stop record PendingL Failure to send and no buffer Idle space available PendingL Failed accounting stop answer Idle received SERVER, STATELESS ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Idle received, and successfully accounting processed. start answer Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Interim record received, Send Idle and successfully processed. accounting answer Idle Accounting stop request Send Idle received, and successfully accounting processed stop answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE SERVER, STATEFUL ACCOUNTING State Event Action New State ------------------------------------------------------------- Idle Accounting start request Send Open received, and successfully accounting processed. start answer, Start Ts Idle Accounting event request Send Idle received, and successfully accounting processed. event answer Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE Open Interim record received, Send Open and successfully processed. accounting answer, Restart Ts Open Accounting stop request Send Idle received, and successfully accounting processed stop answer, Stop Ts Open Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE, Stop Ts Open Session supervision timer Ts Stop Ts Idle expired --------------030509060700090200060006 Content-Type: text/plain; name="diamstatesstillnewdiff.txt" Content-Disposition: inline; filename="diamstatesstillnewdiff.txt" Content-Transfer-Encoding: 7bit 139,141d138 < Open STR Received Send STA, Idle < Cleanup < 145c142,143 < Discon ASR Received with Result-Code Cleanup Idle --- > Discon ASR successfully sent and Cleanup Idle > ASA Received with Result-Code 149,150c147,148 < Result-Code != UNKNOWN_ < SESSION_ID --- > ASA received with Result-Code > != UNKNOWN_SESSION_ID 155,156c153,154 < Not STR Received Send STA, Idle < Open Cleanup --- > Any STR Received Send STA, Idle > Cleanup --------------030509060700090200060006-- From owner-aaa-wg@merit.edu Tue Apr 9 01:52:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18728 for ; Tue, 9 Apr 2002 01:52:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B2D091314; Tue, 9 Apr 2002 01:52:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECC0891316; Tue, 9 Apr 2002 01:52:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0B6791314 for ; Tue, 9 Apr 2002 01:52:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A60F45DE6A; Tue, 9 Apr 2002 01:52:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 4E94F5DE51 for ; Tue, 9 Apr 2002 01:52:12 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g395b8l01863; Tue, 9 Apr 2002 00:37:08 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g395b8P17418; Tue, 9 Apr 2002 00:37:08 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id AAA28869; Tue, 9 Apr 2002 00:37:07 -0500 (CDT) Received: from ericsson.com (racomin-103.exu.ericsson.se [138.85.130.103]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA16073; Tue, 9 Apr 2002 00:37:06 -0500 (CDT) Message-ID: <3CB27D50.A86F4BE6@ericsson.com> Date: Mon, 08 Apr 2002 22:34:08 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: aaa-wg , Sivasundar Ramamurthy Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA References: <3CB04D5A.4030900@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, Johan Johansson wrote: > Issue: HA can not know which ip address to store keys on > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: draft-mip-9 > Comment type: Technical > Priority: S > Section: 4.8 > > This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. > > The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. Will someone really separate the mip control traffic on one interface and the mobile ip tunneling on another? This would mean that every time the HA receives a MIP RRQ from an FA on the mip control interface to update a tunnel endpoint, the HA should not update the tunnel endpoint to this interface, instead the HA must update the mobile ip tunneling interface, which the HA has a pointer to?! Furthermore, I guess this also would mean the HA authenticates (FA-HA auth ext) one interface (the mip control interface) and updates another interface (mip tunnel interface) every time the FA issue a MIP RRQ? As you state above this is not obvious in RFC3220. So, I strongly suggest that people that really believe that this is needed first gets this clarified in the mobile ip wg. I would hate to see that we try to add functionality that may not really be ok according to mobile ip and RFC3220. /Tony From owner-aaa-wg@merit.edu Tue Apr 9 02:04:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24277 for ; Tue, 9 Apr 2002 02:04:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F13B91317; Tue, 9 Apr 2002 02:03:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA707912A5; Tue, 9 Apr 2002 02:03:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B9E191317 for ; Tue, 9 Apr 2002 02:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C2A25DE8D; Tue, 9 Apr 2002 02:03:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id A09335DE51 for ; Tue, 9 Apr 2002 02:03:51 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:03:50 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A946145@cms3.etri.re.kr> From: bglee@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: Minor corrections/clarifications to base-10 about Failed-AVP. Date: Tue, 9 Apr 2002 15:03:49 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF8C.511A5420" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF8C.511A5420 Content-Type: text/plain; charset="euc-kr" Hi, Minor corrections/clarifications to base-10 about Failed-AVP. I wonder, Is this can be Issue ? Regards, Byung-Gil Lee Issue : Minor corrections/clarifications to base-10 about Failed-AVP Submitter name: BG Lee Submitter email address: bglee@etri.re.kr Date first submitted: 04-9-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: ? Section: 7.5 Failed-AVP AVP In section 7.5 Failed-AVP, 7.5 Failed-AVP AVP ...presence of two or more occurrences of an AVP which is restricted to 0, 1, or 0-1 occurrences. .. A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the omitted AVP will be added. but... Currently, there is no way to enter the two or more Reason Code in Result- Code AVP and it is difficuit to match the Result-Code AVP and Failed-AVP. so... Existing : 7.5 Failed-AVP AVP AVP Format ::= < AVP Header: 279 > 1* {AVP} Requested change: AVP Format ::= < AVP Header: 279 > 1* { {Result-Code AVP}/*Following AVP's Error Cause Value included*/ {AVP} } ------_=_NextPart_001_01C1DF8C.511A5420 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Minor corrections/clarifications to base-10 about Failed-AVP. =

Hi,

Minor corrections/clarifications to base-10 about = Failed-AVP.
I wonder, Is this can be Issue ?
Regards,
Byung-Gil Lee



Issue = :            = ;     Minor corrections/clarifications to base-10 = about Failed-AVP
Submitter = name:         BG Lee
Submitter email address: bglee@etri.re.kr
Date first submitted:   04-9-2002
Reference:
Document:         =       draft-base-10
Comment = type:           = Technical
Priority:         =       ?
Section:        =         =         7.5  Failed-AVP = AVP

In section 7.5 Failed-AVP,

7.5  Failed-AVP AVP

...presence of two or more occurrences of an AVP = which is restricted to 0, 1, or 0-1
occurrences.
..   A Diameter message MAY contain one = Failed-AVP AVP, containing the
   entire AVP that could not be processed = successfully. If the failure  reason is omission
of a required AVP, an AVP with the missing AVP code, = the missing vendor id, and
a zero filled payload of the minimum required length = for the omitted AVP will be added.


but...
Currently, there is no way to enter the two or more = Reason Code in Result-Code  AVP
and it is difficuit to match the Result-Code AVP and = Failed-AVP.
so...


Existing :


7.5  Failed-AVP AVP

      AVP Format

      <Failed-AVP> = ::=3D < AVP Header: 279 >
          &nb= sp;         1* {AVP}


Requested change:


   AVP Format

      <Failed-AVP> = ::=3D < AVP Header: 279 >
        =         =         =         =         1* {
        =         =         =         =         =         =         {Result-Code = AVP}/*Following AVP's Error Cause Value included*/
        =             =             = {AVP}
        =         =         =         =         =         }

------_=_NextPart_001_01C1DF8C.511A5420-- From owner-aaa-wg@merit.edu Tue Apr 9 02:11:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27216 for ; Tue, 9 Apr 2002 02:11:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B59E3912A5; Tue, 9 Apr 2002 02:11:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D73791316; Tue, 9 Apr 2002 02:11:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67A7D912A5 for ; Tue, 9 Apr 2002 02:11:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 262825DEA0; Tue, 9 Apr 2002 02:11:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id E63D15DE51 for ; Tue, 9 Apr 2002 02:11:21 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g395uMi19528; Tue, 9 Apr 2002 00:56:22 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g395uLu15842; Tue, 9 Apr 2002 00:56:21 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id AAA00466; Tue, 9 Apr 2002 00:56:21 -0500 (CDT) Received: from ericsson.com (racomin-103.exu.ericsson.se [138.85.130.103]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA16327; Tue, 9 Apr 2002 00:56:19 -0500 (CDT) Message-ID: <3CB281D2.699ED893@ericsson.com> Date: Mon, 08 Apr 2002 22:53:22 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: aaa-wg , Sivasundar Ramamurthy Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA References: <3CB04D5A.4030900@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, Johan Johansson wrote: > Issue: HA can not know which ip address to store keys on > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: draft-mip-9 > Comment type: Technical > Priority: S > Section: 4.8 > > This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. > > The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. Will someone really separate the mip control traffic on one interface and the mobile ip tunneling on another? This would mean that every time the HA receives a MIP RRQ from an FA on the mip control interface to update a tunnel endpoint, the HA should not update the tunnel endpoint to this interface, instead the HA must update the mobile ip tunneling interface, which the HA has a pointer to?! Furthermore, I guess this also would mean the HA authenticates (FA-HA auth ext) one interface (the mip control interface) and updates another interface (mip tunnel interface) every time the FA issue a MIP RRQ? As you state above this is not obvious in RFC3220. So, I strongly suggest that people that really believe that this is needed first gets this clarified in the mobile ip wg. I would hate to see that we try to add functionality that may not really be ok according to mobile ip and RFC3220. /Tony From owner-aaa-wg@merit.edu Tue Apr 9 09:40:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04892 for ; Tue, 9 Apr 2002 09:40:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E6532912AC; Tue, 9 Apr 2002 09:40:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF27912AD; Tue, 9 Apr 2002 09:40:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87758912AC for ; Tue, 9 Apr 2002 09:40:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6249F5DE34; Tue, 9 Apr 2002 09:40:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id C4F295DE32 for ; Tue, 9 Apr 2002 09:40:35 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g39Ddfu05230 for ; Tue, 9 Apr 2002 16:39:41 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Apr 2002 16:40:28 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Apr 2002 16:40:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #318 Host-IP-Address AVP in CER and CEA is redundant - rejected Date: Tue, 9 Apr 2002 16:40:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E45@esebe004.NOE.Nokia.com> Thread-Topic: Issue #318 Host-IP-Address AVP in CER and CEA is redundant - rejected Thread-Index: AcHfzBm7U39j9kE2TT6n3PdZ87cUwQ== From: To: X-OriginalArrivalTime: 09 Apr 2002 13:40:27.0561 (UTC) FILETIME=[1BC9B190:01C1DFCC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04892 Hello all, Issue #318 Host-IP-Address AVP in CER and CEA is redundant has been rejected. So far, noone spoke up in favor of this while several people have suggested it be rejected. John From owner-aaa-wg@merit.edu Tue Apr 9 09:43:01 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05004 for ; Tue, 9 Apr 2002 09:43:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A988912AD; Tue, 9 Apr 2002 09:42:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1D56912AF; Tue, 9 Apr 2002 09:42:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61C76912AD for ; Tue, 9 Apr 2002 09:42:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 480B15DE38; Tue, 9 Apr 2002 09:42:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 84B4D5DE34 for ; Tue, 9 Apr 2002 09:42:14 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g39DgF518917 for ; Tue, 9 Apr 2002 16:42:15 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Apr 2002 16:41:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Apr 2002 16:41:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #324 New generic host identification AVPs - rejected Date: Tue, 9 Apr 2002 16:41:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E46@esebe004.NOE.Nokia.com> Thread-Topic: Issue #324 New generic host identification AVPs - rejected Thread-Index: AcHfzDShMKuS0c5jTveczL6LeQtiCg== From: To: X-OriginalArrivalTime: 09 Apr 2002 13:41:13.0662 (UTC) FILETIME=[374425E0:01C1DFCC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05004 Hello all, Issue #324 New generic host identification AVPs has been rejected, as noone has expressed interest in it. John From owner-aaa-wg@merit.edu Tue Apr 9 09:43:31 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05032 for ; Tue, 9 Apr 2002 09:43:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 947C3912AF; Tue, 9 Apr 2002 09:42:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 578FC912B0; Tue, 9 Apr 2002 09:42:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75EE3912AF for ; Tue, 9 Apr 2002 09:42:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 576235DE34; Tue, 9 Apr 2002 09:42:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 8AE555DE32 for ; Tue, 9 Apr 2002 09:42:31 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g39DhFJ03117 for ; Tue, 9 Apr 2002 16:43:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Apr 2002 16:42:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Apr 2002 16:42:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #325 Minor clarifications/corrects to Base-10/2 - closed Date: Tue, 9 Apr 2002 16:42:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E47@esebe004.NOE.Nokia.com> Thread-Topic: Issue #325 Minor clarifications/corrects to Base-10/2 - closed Thread-Index: AcHfzFnajR70Li5xSdKbINKE5a+LEw== From: To: X-OriginalArrivalTime: 09 Apr 2002 13:42:15.0102 (UTC) FILETIME=[5BE325E0:01C1DFCC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05032 Hello all, Issue #325 Minor clarifications/corrects to Base-10/2 has been added to draft 10, so this issue is now closed. John From owner-aaa-wg@merit.edu Tue Apr 9 12:03:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10573 for ; Tue, 9 Apr 2002 12:03:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D44549131E; Tue, 9 Apr 2002 12:03:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C68F2912C5; Tue, 9 Apr 2002 12:03:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7CF5912B2 for ; Tue, 9 Apr 2002 12:01:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9A225DE89; Tue, 9 Apr 2002 12:01:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id ECF325DDB3 for ; Tue, 9 Apr 2002 12:01:32 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g39G5A4b030315; Tue, 9 Apr 2002 18:05:10 +0200 From: "Fredrik Johansson" To: "MobileIP" , "AAA Listan" Subject: [AAA-WG]: draft-johansson-mip-aaa-nai-01.txt Date: Tue, 9 Apr 2002 18:01:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi I have submitted a new version of the AAA NAI draft. Until officially announced, it is available at http://stargate.ipunplugged.com/ietf/draft-johansson-mip-aaa-nai-01.txt As always, comments appreciated /Fredrik From owner-aaa-wg@merit.edu Tue Apr 9 15:56:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19427 for ; Tue, 9 Apr 2002 15:56:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4002D912B8; Tue, 9 Apr 2002 15:56:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF236912B9; Tue, 9 Apr 2002 15:56:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00BB8912B8 for ; Tue, 9 Apr 2002 15:56:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4BFA5DEBC; Tue, 9 Apr 2002 15:56:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id ECEE95DDBF for ; Tue, 9 Apr 2002 15:56:16 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g39JuGl13966 for ; Tue, 9 Apr 2002 14:56:16 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g39JuFV13790 for ; Tue, 9 Apr 2002 14:56:15 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA27721 for ; Tue, 9 Apr 2002 14:56:15 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA28886 for ; Tue, 9 Apr 2002 14:56:14 -0500 (CDT) Message-ID: <3CB346AB.4D8E63E0@ericsson.com> Date: Tue, 09 Apr 2002 12:53:15 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: updated text proposal to issue #299 and #301 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, Thanks a lot for all the previous comments. Here is an updated text proposal to issue #299 and #301. Since I have made various changes through out section 1.2, 1.3 and 1.4, I've added the whole sections below. And as always, comments are appreciated. /Tony ---------------------------------------------------------------------- 1.2 Inter-Realm Mobile IP When a Mobile Node node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA- Mobile-Node-Request (AMR) message, which includes the AVPs defined in section 2.1. The Home Address, Home Agent, Mobile Node NAI and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF. Visited Realm Home Realm +--------+ +--------+ |abc.com | AMR/AMA |xyz.com | | AAAF |<------------------->| AAAH | +->| server | server-server | server | | +--------+ communication +--------+ | ^ ^ | AMR/AMA | client-server | HAR/HAA | | communication | v v v +---------+ +---------+ +---------+ | Foreign | | Foreign | | Home | | Agent | | Agent | | Agent | +---------+ +---------+ +---------+ ^ | Mobile IP | v +--------+ | Mobile | | Node | mn@xyz.com +--------+ Figure 1: Inter-Realm Mobility Upon receiving the AMR, the AAAF follows the procedures outlined in [DIAMBASE] to determine whether the AMR should be processed locally, or if it should be forwarded to another Diameter server, known as the AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node (mn@xyz.com) requests service from a foreign provider (abc.com). The request received by the AAAF is forwarded to xyz.com's AAAH server. Figure 2 shows the message flows involved when the foreign agent invokes the AAA infrastructure to request that a mobile node be authenticated and authorized. Note that it is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile, but rather only when the prior authorization from the AAAH expires [MIPCHAL]. The expiration time of the authorization is communicated through the Authorization-Lifetime AVP in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. Mobile Node Foreign Agent AAAF AAAH Home Agent ----------- ------------- ------------ ---------- ---------- Advertisement & <--------- Challenge Reg-Req&MN-AAA ----> AMR------------> Session-Id = foo AMR------------> Session-Id = foo HAR-----------> Session-Id = bar <----------HAA Session-Id = bar <-----------AMA Session-Id = foo <------------AMA Session-Id = foo <-------Reg-Reply Figure 2: Mobile IP/Diameter Message Exchange The foreign agent (as shown in Figure 2) MAY provide a challenge, which gives it direct control over the replay protection in the Mobile IP registration process, as described in [MIPCHAL]. The mobile node includes the Challenge and MN-AAA authentication extension to enable authorization by AAAH. If the authentication data supplied in the MN-AAA extension is invalid, AAAH returns the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED. A mobile node, which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, in the registration request message [AAANAI] which is sent to the FA every time the Mobile Node needs to re-authenticate. So, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and realm of the assigned HA found in the HA-NAI. If the mobile node was successfully authenticated, the AAAH checks if the home agent was located in the foreign realm, by checking Home- Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- Foreign-AAA AVP may also be used to verify the location of the home agent. If the home agent is located in the foreign realm, then the AAAH sends an HAR message to the home agent, which contains a MIP- Reg-Request AVP. If the home agent was not located in the foreign realm, the AAAH checks for the MIP-Home-Agent-Address AVP and if present the MIP- Home-Agent-Host AVP. If one was specified, the AAAH checks that the address is that of a known home agent and that the Mobile Node is allowed to request this particular home agent, and that the home agent's identity is included in the MIP-Home-Agent-Host AVP. If no home agent was specified, and if the MIP-Feature-Vector has the Home- Agent-Requested flag set, and if allowed by policy in the home realm, the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This can be done in a variety of ways, including using a load balancing algorithm in order to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents is outside the scope of this specification. The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a home address for the mobile node, while the Home Agent MUST support home address allocation. In the event the AAAH handles address allocation, it includes it in a MIP-Mobile-Node- Address AVP within the HAR. The absence of this AVP informs the Home Agent to perform the allocation. During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see Figure 2). If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR. A mobile node's session is identified via its identity in the User- Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [DIAMBASE], to be used unmodified with this application. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the one towards the home agent (see figure 3). STR, Session-Id = foo STR, Session-Id = bar ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> STA, Session-Id = foo STA, Session-Id = bar Figure 3: Session Termination and Session Identifiers Upon receipt of the HAR, the home agent first processes the Diameter message. The home agent processes the MIP-Reg-Request AVP and creates the Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. In the creation of the Registration Reply the Home Agent must include the HA NAI and the AAAH NAI, which will be created from the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and within the MIP-Mobile-Node-Address AVP. The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA returned to the AAAH. Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, includes the Accounting-Multi-Session-Id that was present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- Address AVPs in the AMA message, enabling appropriate firewall controls for the penetration of tunneled traffic between the Home Agent and the Mobile Node. 1.3 Support for Mobile IP Handoffs Given the nature of Mobile IP, a mobile node MAY receive service from many foreign agents during a period of time. However, the home realm should not view these handoffs as different sessions, since this could affect billing systems. Furthermore, many foreign agents do not communicate, which makes it quite difficult for AAA information to be exchanged between these entities. Therefore, it MUST be assumed that a foreign agent is not aware that a registration request from a mobile node has been previously authorized. A handoff registration request from a mobile node will cause an AMR to be sent to its AAAF. The AMR will include a new session identifier, and MAY be sent to an AAAF in the visited network other than the AAAF, which received the previous AMR. However, with the usage of the AAA NAI, this AMR is guaranteed to be received by the AAAH to which the user is currently registered. Since the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier. It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, the home agent MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Accounting-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. This Accounting-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Accounting-Multi-Session-Id in the accounting messages. ACR, Session-Id = foo ACR, Session-Id = bar Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> ACA, Session-Id = foo ACA, Session-Id = bar Figure 4: Accounting messages w/ Mobile IP Application 1.4 Allocation of Home Agent in Foreign Network The Diameter Mobile IP application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home- Agent- Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to zero. When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- Agent-Host AVP contains the identity of the home agent that would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. In the event that the mobile node has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP- Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a Home Agent for the mobile node, i.e. the Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or the AMR indicates that the AAAF has offered a previously allocated Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- Network is set in the MIP-Feature-Vector AVP, then the AAAH must decide whether its local policy would allow the user to have a Home Agent in the foreign network or to keep the Home Agent in the foreign network. If so, and after checking authorization from the data in the AMR message, the AAAH sends the HAR message to Home Agent by including the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if the HA has been previously allocated and authorized by the AAAH. If the HA has not been previously allocated by the foreign domain, the HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. The HAR sent by the AAAH back to the foreign realm with the Destination-Host AVP set to the home agent's identity, may not necessarily be received by the same AAAF, which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, the new AAAF will use the MIP-Originating- Foreign-AAA AVP for policy decisions, such as determining if the FA- HA Key should be encrypted or not. If on the other hand, the AAAH local policy determines that the MN-HA Key and the MN-FA Key must be encrypted and no security association is known to the home agent, the AAAH SHOULD send the HAR to the originating AAAF by including the Destination-Host AVP set to the value found in the AMR's MIP- Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR. Visited Home Realm Realm +--------+ ------- AMR -------> +--------+ | AAAF | <------ HAR -------- | AAAH | | | | | +--->| server | ------- HAA -------> | server | | +--------+ <------ AMA -------- +--------+ | ^ | | | | HAR/HAA | AMR | | AMA v | v +---------+ +---------+ | Home | | Foreign | | Agent | | Agent | +---------+ +---------+ ^ +--------+ | | Mobile |<----------+ | Node | Mobile IP +--------+ Figure 5: Home Agent allocated in Visited Realm Upon receipt of a HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed, and issued to the AAAF, and finally to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP- Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. Mobile Node Foreign Agent Home Agent AAAF AAAH ----------- ------------- ------------- ---------- ---------- <----Challenge---- Reg-Req (Response)-> ------------AMR-------------> -----AMR----> <----HAR----- <-----HAR------ ------HAA------> -----HAA----> <----AMA----- <-------------AMA------------ <---Reg-Reply---- Figure 6: Mobile IP/Diameter Message Exchange If the Mobile Node moves to another Foreign Network, it MAY either request to keep the same Home Agent within the old foreign network, or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the mobile node will have to be serviced by two AAAFs. Figure 7 shows the message flows for a mobile node requesting to keep the home agent assigned in foreign network 1 when it moves to foreign network 2. Upon reception of the AMR in Foreign network 2, the AAAF follows the procedures described earlier and forwards AMR to the mobile node's home network, i.e. its AAAH. If the mobile node was successfully authenticated, the AAAH checks the identity of the foreign and home agent to determine whether the user is in a third realm. If this is the case, the AAAH must check whether the mobile is still permitted to use the previously assigned home agent. +---------------+ +---------------+ +-------------+ |Foreign net 2 | |Foreign net 1 | |Home network | | | | | | | Mobile Node | FA AAAF | | HA AAAF | | AAAH | ----------- | ---- ---- | | ---- ------ | | ------ | +---------------+ +---------------+ +-------------+ <----Challenge---- Reg-Req (Response)-> ---AMR---> ----------------AMR---------------> <-----HAR----- <---HAR---- ----HAA---> ------HAA----> <---------------AMA---------------- <--AMA---- <----Reg-Reply----- Figure 7: Request to access Home Agent from new Foreign Network If the mobile node is allowed to keep the home agent the AAAH then sends a HAR, which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP and the MIP- Home-Agent-Address AVP with home agent address, as well as any optional KDC session keys, to the AAAF in foreign network 1. Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA AVP from AMR and include it in the HAR when a third foreign domain is involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not. Upon reception the AAAF in foreign network 1 will forward the HAR to the Home Agent if its local policy allows such service. If the AAAF does not permit such service, it MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If the AAAH local policy determines that the MN-HA Key must be encrypted and no security association is known to the home agent, the AAAH MUST send the HAR to the AAAF in foreign network 1, which originally assigned the HA in foreign network 1, by including its identity in the Destination-Host AVP. When the AAAF receives a HAA, the AAAF will forward the HAA back to the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an AMA to the AAAF in foreign network 2. If the old Foreign Network does not permit the use of its Home Agent when the Mobile Node moves to a new foreign network, the AAAH or AAAF MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile Node with an appropriate error. The Mobile Node MAY attempt to request that a new Home Agent and Address be allocated. When the AAAH transmits such an error, it MUST issue a Diameter Abort-Session- Request message to the Home Agent to enable it to release any resources. .... 2.1 AA-Mobile-Node-Request .... The foreign agent (or home agent in the case of a co-located mobile mode)uses information found in the Registration Request to construct the following AVPs that are to be included as part of the AMR: .... home agent NAI (MIP-Home-Agent-Host AVP) home AAA server NAI (Destination-Host AVP [DIAMBASE]) ... If the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home- Agent-Host AVP and the Destination-Host AVP in the AMR. Message Format ::= < Diameter Header: 260, REQ, PXY > < Session-ID > { Auth-Application-Id } { User-Name } { Destination-Realm } { Origin-Host } { Origin-Realm } { MIP-Reg-Request } { MIP-MN-AAA-Auth } [ Destination-Host ] [ Origin-State-Id ] [ MIP-Mobile-Node-Address ] [ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host] [ MIP-Feature-Vector ] [ MIP-Originating-Foreign-AAA ] [ Authorization-Lifetime ] [ Auth-Session-State ] [ MIP-FA-Challenge ] [ MIP-Candidate-Home-Agent-Host ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] .... 4.12 MIP-Home-Agent-Host AVP The MIP-Home-Agent-Host AVP (AVP Code TBD) if of type Grouped, and contains the identity of the assigned Home Agent. If present in the AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. MIP-Home-Agent-Host ::= < AVP Header: TBD > { Destination-Realm } { Destination-Host } * [ AVP ] .... 5.3 Distributing the Mobile-Home Session Key .... If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent. If the session key needs to be encrypted the AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data AVP using the security association with the home agent or with the AAAF associated with the home agent. If no security association is known the home agent, the AAAH will check if a security association can be established using DSA messages defined in the CMS application [CMS] with the originating host found in the MIP-Originating-Foreign- AAA AVP and if the DSA establishment is successful, the AAAH will encrypt the MIP-HA-to-MN Key AVP with the established security association. On the other hand, if no security association exists and the DSA establishment fails, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. .... 11.1 Normative .... [AAANAI] F.Johansson, T.Johansson, "AAA NAI for Mobile IPv4 Exten­ sion", draft-johansson-mip-aaa-nai-01.txt, IETF work in progress, September 2002. [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions". RFC 3012. November 2000. .... 11.2 Informative .... [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-05.txt, IETF work in progress, November 2001. .... From owner-aaa-wg@merit.edu Tue Apr 9 18:23:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24703 for ; Tue, 9 Apr 2002 18:23:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56504912CF; Tue, 9 Apr 2002 18:22:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B9D7912CE; Tue, 9 Apr 2002 18:22:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC6FA912C3 for ; Tue, 9 Apr 2002 18:22:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCE4A5DE36; Tue, 9 Apr 2002 18:22:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 2850F5DD91 for ; Tue, 9 Apr 2002 18:22:50 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020409222249.DIUK12824.fep01-svc.swip.net@ipunplugged.com>; Wed, 10 Apr 2002 00:22:49 +0200 Message-ID: <3CB36A02.2040401@ipunplugged.com> Date: Wed, 10 Apr 2002 00:24:02 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg , Sivasundar Ramamurthy , frej Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA References: <3CB04D5A.4030900@ipunplugged.com> <3CB281D2.699ED893@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, My reasoning behind my proposition was that no harm is done if it is sent redundantly, but potentially great harm is done if it is not sent. You ask if anyone will really separate control traffic and mobile ip tunneling. I don't know. I'd prefer to not make assumptions, but my favourite solution would be for the mip-wg to state that the CoA is the one to use. Fredrik has been taking that discussion with the mip-wg but since I am currently at home ill I have not had time to follow up on what response he has got. There is nothing in RFC3220 as far as I can see that forbids the behaviour I describe. Can we at least agree that it is wrong to copy the Origin-Host AVP in the AMR and use it for this purpose? j Tony Johansson wrote: >Hi Johan, > >Johan Johansson wrote: > >>Issue: HA can not know which ip address to store keys on >>Submitter name: Johan Johansson >>Submitter email address: johanj@ipunplugged.com >>Date first submitted: 04-07-2002 >>Reference: >>Document: draft-mip-9 >>Comment type: Technical >>Priority: S >>Section: 4.8 >> >>This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. >> >>The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. >> > >Will someone really separate the mip control traffic on one interface and the mobile ip tunneling on another? This would mean that every time the HA receives a MIP RRQ from an FA on the mip control interface to update a tunnel endpoint, the HA should not update the tunnel endpoint to this interface, instead the HA must update the mobile ip tunneling interface, which the HA has a pointer to?! Furthermore, I guess this also would mean the HA authenticates (FA-HA auth ext) one interface (the mip >control interface) and updates another interface (mip tunnel interface) every time the FA issue a MIP RRQ? > >As you state above this is not obvious in RFC3220. So, I strongly suggest that people that really believe that this is needed first gets this clarified in the mobile ip wg. I would hate to see that we try to add functionality that may not really be ok according to mobile ip and RFC3220. > >/Tony > > > > From owner-aaa-wg@merit.edu Tue Apr 9 20:10:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26185 for ; Tue, 9 Apr 2002 20:10:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCE9B9121F; Tue, 9 Apr 2002 20:10:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B116D912C9; Tue, 9 Apr 2002 20:10:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9051E9121F for ; Tue, 9 Apr 2002 20:10:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EE025DF06; Tue, 9 Apr 2002 20:10:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 408CB5DDC0 for ; Tue, 9 Apr 2002 20:10:03 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 3706F400298; Tue, 9 Apr 2002 17:09:57 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id RAA16582; Tue, 9 Apr 2002 17:10:50 -0700 (PDT) Date: Tue, 9 Apr 2002 17:10:49 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: Johan Johansson , aaa-wg Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA In-Reply-To: <3CB27D50.A86F4BE6@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, > As you state above this is not obvious in RFC3220. So, I strongly > suggest that people that really believe that this is needed first > gets this clarified in the mobile ip wg. I would hate to see that > we try to add functionality that may not really be ok according to > mobile ip and RFC3220. RFC3220 allows registering with the FA using a co-located address (R bit set in advertisement). This is a scenario where the COA (tunnel endpoint) is not the address of the FA's control interface. thanks, Siva From owner-aaa-wg@merit.edu Tue Apr 9 21:01:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26868 for ; Tue, 9 Apr 2002 21:01:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E868912D0; Tue, 9 Apr 2002 21:00:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E1AA912D3; Tue, 9 Apr 2002 21:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1C09912D0 for ; Tue, 9 Apr 2002 21:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B85655DE03; Tue, 9 Apr 2002 21:00:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 1147F5DD8F for ; Tue, 9 Apr 2002 21:00:44 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 10:00:42 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A946148@cms3.etri.re.kr> From: bglee@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Date: Wed, 10 Apr 2002 10:00:41 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E02B.230FAD10" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E02B.230FAD10 Content-Type: text/plain; charset="euc-kr" Hi All. If Failed-AVP MAY contain two or more AVPs, I think that Failed-AVP is not sufficient. It should contain a list of error cause code. For example we can consider multiple failed AVP, Result-Code AVPs of error cause types should contain. so, I suggest the modified Failed AVP... Please, some comments. ---------------------------------------------------------------------- Minor corrections/clarifications to base-10 about Failed-AVP. I wonder, Is this can be Issue ? Regards, Byung-Gil Lee ETRI Information Security Technology Division Issue : What is Result Cause Value ? In multi-Failed AVP Case. Submitter name: BG Lee Submitter email address: bglee@etri.re.kr Date first submitted: 04-9-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: ? Section: 7.5 Failed-AVP AVP In section 7.5 Failed-AVP, 7.5 Failed-AVP AVP The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. ... but... Currently, there is no way to enter the two or more Reason Code in Result- Code AVP and it is difficult to match the Result-Code AVP and Failed-AVP. so... Existing : 7.5 Failed-AVP AVP AVP Format ::= < AVP Header: 279 > 1* {AVP} Requested change: AVP Format ::= < AVP Header: 279 > 1* { 1* {Result-Code AVP}/*Following AVP's Error Cause Value included*/ {AVP} } ---------------------------------------------------------- Byung-Gil Lee Electronics and Telecommunications Research Institute, KOREA ---------------------------------------------------------- ------_=_NextPart_001_01C1E02B.230FAD10 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable What is Result Cause Value ? In Multi-Failed AVP Case.

Hi All.
 
If Failed-AVP MAY contain two or more AVPs, I think = that Failed-AVP is not sufficient. 
It should contain a list of error cause code. =
For example we can consider multiple failed AVP, =
Result-Code AVPs of error cause types should = contain.

so,

I suggest the modified Failed AVP...
Please, some comments.

---------------------------------------------------------------= -------

Minor corrections/clarifications to base-10 about = Failed-AVP.
I wonder, Is this can be Issue ?
Regards,
Byung-Gil Lee
ETRI Information Security Technology Division
 

Issue = :            = ;     What is Result Cause Value ?  In = multi-Failed AVP Case.
Submitter = name:         BG Lee
Submitter email address: bglee@etri.re.kr
Date first submitted:   04-9-2002
Reference:
Document:         =       draft-base-10
Comment = type:           = Technical
Priority:         =       ?
Section:         &= nbsp;           &= nbsp;  7.5  Failed-AVP AVP


In section 7.5 Failed-AVP,
 

7.5  Failed-AVP AVP

The Failed-AVP AVP (AVP Code 279) is of type Grouped = and provides debugging
information in cases where a request is rejected or = not fully processed due to
erroneous information in a specific AVP. The value = of the Result-Code AVP will
provide information on the reason for the Failed-AVP = AVP.
...

 

 

but...
Currently, there is no way to enter the two or more = Reason Code in Result-Code  AVP
and it is difficult to match the Result-Code AVP and = Failed-AVP.
so...



Existing :

 

7.5  Failed-AVP AVP


      AVP Format
      <Failed-AVP> = ::=3D < AVP Header: 279 >
          &nb= sp;         1* {AVP}



Requested change:



   AVP Format

    <Failed-AVP> ::=3D < AVP = Header: 279 >
          &nb= sp; 1* {
          &nb= sp;           1* = {Result-Code AVP}/*Following AVP's Error Cause Value included*/
          &nb= sp;             =   {AVP}
          &nb= sp;       }


----------------------------------------------------------
Byung-Gil Lee
Electronics and Telecommunications
Research Institute, KOREA
----------------------------------------------------------


------_=_NextPart_001_01C1E02B.230FAD10-- From owner-aaa-wg@merit.edu Tue Apr 9 21:44:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28367 for ; Tue, 9 Apr 2002 21:44:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F247912D1; Tue, 9 Apr 2002 21:44:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12C88912D3; Tue, 9 Apr 2002 21:44:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA91D912D1 for ; Tue, 9 Apr 2002 21:44:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B551E5DE11; Tue, 9 Apr 2002 21:44:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 2E2DF5DD8F for ; Tue, 9 Apr 2002 21:44:38 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3A1ial12596; Tue, 9 Apr 2002 20:44:36 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3A1iaR28827; Tue, 9 Apr 2002 20:44:36 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id UAA04182; Tue, 9 Apr 2002 20:44:36 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA03703; Tue, 9 Apr 2002 20:44:35 -0500 (CDT) Message-ID: <3CB39850.CD587982@ericsson.com> Date: Tue, 09 Apr 2002 18:41:36 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Johan Johansson , aaa-wg Subject: Re: [AAA-WG]: HA can not know which ip address to use for it'ssecurity association with the FA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, Sivasundar Ramamurthy wrote: > Hi Tony, > > > As you state above this is not obvious in RFC3220. So, I strongly > > suggest that people that really believe that this is needed first > > gets this clarified in the mobile ip wg. I would hate to see that > > we try to add functionality that may not really be ok according to > > mobile ip and RFC3220. > > RFC3220 allows registering with the FA using a co-located address (R > bit set in advertisement). This is a scenario where the COA (tunnel > endpoint) is not the address of the FA's control interface. I'm sorry but really don't understand what you try to arguing here. A "co-located care-of address" is a care-of address acquired by the mobile node as a local IP address through some external means, which the mobile node then associates with one of it own network interfaces. The mode of using a co-located care-of address has the advantage that it allows a mobile node to function without a foreign agent, for example, in networks that have not yet deployed a foreign agent. The R bit set in the advertisement, which you refer to above, tells the MN that registration with a foreign agent is required even when using a co-located care-of address. So, why would this R-bit have anything to do with allowing a mip control interface and a mip tunneling interface?! /Tony From owner-aaa-wg@merit.edu Tue Apr 9 21:49:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28431 for ; Tue, 9 Apr 2002 21:49:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D07A912D6; Tue, 9 Apr 2002 21:48:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12B87912D3; Tue, 9 Apr 2002 21:48:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 960DF912D6 for ; Tue, 9 Apr 2002 21:47:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74DCD5DE11; Tue, 9 Apr 2002 21:47:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F12C45DD8F for ; Tue, 9 Apr 2002 21:47:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3A14GO21928 for ; Tue, 9 Apr 2002 18:04:16 -0700 Date: Tue, 9 Apr 2002 18:04:16 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Last Call on draft-ietf-aaa-transport-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on the "Authentication, Authorization and Accounting (AAA) Transport Profile" document, before sending this on to the IESG for consideration as a Proposed Standard. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-06.txt Please post issues with this document to aaa-wg@merit.edu by April 25, 2002, using the issue format described on the AAA issues list at: http://www.drizzle.com/~aboba/AAA/issues.html Note that the intent is for this to be the last AAA WG last call on this document, so if you have not read it carefully lately, now is the time. From owner-aaa-wg@merit.edu Wed Apr 10 08:38:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17298 for ; Wed, 10 Apr 2002 08:38:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEBB991227; Wed, 10 Apr 2002 08:38:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96B38912DD; Wed, 10 Apr 2002 08:38:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4A9491227 for ; Wed, 10 Apr 2002 08:38:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E5F55DDC7; Wed, 10 Apr 2002 08:38:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 63D045DDA8 for ; Wed, 10 Apr 2002 08:38:32 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 0689E79; Wed, 10 Apr 2002 08:38:31 -0400 (EDT) From: "Bob Kopacz" To: , , Cc: Subject: RE: [AAA-WG]: RE: [issue]: New generic host identification AVPs Date: Wed, 10 Apr 2002 08:37:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E12@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, I am sorry for my sluggish response. I've been elsewhere the last few days. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, April 08, 2002 7:23 AM > To: BKopacz@interlinknetworks.com; tony.johansson@ericsson.com; > DSpence@interlinknetworks.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: RE: [issue]: New generic host identification AVPs > > Bob, > > What is the damage if this is not done? I don't think there is any damage if this is not done. I think the proposal cleans things up a bit, is all. Bob K. > > John From owner-aaa-wg@merit.edu Wed Apr 10 10:11:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20178 for ; Wed, 10 Apr 2002 10:11:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4B2591207; Wed, 10 Apr 2002 10:11:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0C179122D; Wed, 10 Apr 2002 10:11:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0B6F91207 for ; Wed, 10 Apr 2002 10:11:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3D2E5DDAF; Wed, 10 Apr 2002 10:11:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 867285DDA8 for ; Wed, 10 Apr 2002 10:11:36 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id C7C5879; Wed, 10 Apr 2002 10:11:35 -0400 (EDT) From: "Bob Kopacz" To: "Tony Johansson" , Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Wed, 10 Apr 2002 10:10:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CB346AB.4D8E63E0@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Tony, > From: owner-aaa-wg@merit.edu on behalf of Tony Johansson > [tony.johansson@ericsson.com] > Sent: Tuesday, April 09, 2002 3:53 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: updated text proposal to issue #299 and #301 > > All, > > Thanks a lot for all the previous comments. Here is an updated text > proposal to issue #299 and #301. Since I have made various changes > through out section 1.2, 1.3 and 1.4, I've added the whole sections > below. > > And as always, comments are appreciated. OK. Here's some comments to appreciate :) > /Tony > > ---------------------------------------------------------------------- > > 1.2 Inter-Realm Mobile IP > > When a Mobile Node node requests service by issuing a Registration > Request to the foreign agent, the foreign agent creates the AA- > Mobile-Node-Request (AMR) message, which includes the AVPs defined in > section 2.1. The Home Address, Home Agent, Mobile Node NAI and other > important fields are extracted from the registration messages for > possible inclusion as Diameter AVPs. The AMR message is then > forwarded to the local Diameter server, known as the AAA-Foreign, or > AAAF. > > Visited Realm Home Realm > +--------+ +--------+ > |abc.com | AMR/AMA |xyz.com | > | AAAF |<------------------->| AAAH | > +->| server | server-server | server | > | +--------+ communication +--------+ > | ^ ^ > | AMR/AMA | client-server | HAR/HAA > | | communication | > v v v > +---------+ +---------+ +---------+ > | Foreign | | Foreign | | Home | > | Agent | | Agent | | Agent | > +---------+ +---------+ +---------+ > ^ > | Mobile IP > | > v > +--------+ > | Mobile | > | Node | mn@xyz.com > +--------+ > > Figure 1: Inter-Realm Mobility > > Upon receiving the AMR, the AAAF follows the procedures outlined in > [DIAMBASE] to determine whether the AMR should be processed locally, > or if it should be forwarded to another Diameter server, known as the > AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node > (mn@xyz.com) requests service from a foreign provider (abc.com). The > request received by the AAAF is forwarded to xyz.com's AAAH server. > > Figure 2 shows the message flows involved when the foreign agent > invokes the AAA infrastructure to request that a mobile node be > authenticated and authorized. Note that it is not required that the > foreign agent invoke AAA services every time a Registration Request > is received from the mobile, but rather only when the prior > authorization from the AAAH expires [MIPCHAL]. The expiration time of the > authorization is communicated through the Authorization-Lifetime AVP > in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. > > Mobile Node Foreign Agent AAAF AAAH Home Agent > ----------- ------------- ------------ ---------- ---------- > Advertisement & > <--------- Challenge > > Reg-Req&MN-AAA ----> > > AMR------------> > Session-Id = foo > > AMR------------> > Session-Id = foo > > HAR-----------> > Session-Id = bar > > <----------HAA > Session-Id = bar > > <-----------AMA > Session-Id = foo > > <------------AMA > Session-Id = foo > > <-------Reg-Reply > > Figure 2: Mobile IP/Diameter Message Exchange > > The foreign agent (as shown in Figure 2) MAY provide a challenge, > which gives it direct control over the replay protection in the > Mobile IP registration process, as described in [MIPCHAL]. The > mobile node includes the Challenge and MN-AAA authentication > extension to enable authorization by AAAH. If the authentication data > supplied in the MN-AAA extension is invalid, AAAH returns the > response (AMA) with the Result-Code AVP set to > DIAMETER_AUTHENTICATION_REJECTED. > > A mobile node, which has been previously authenticated and > authorized, MUST always include the assigned home agent in the HA > Identity subtype of the AAA NAI extension, and the authorizing Home > AAA server in the AAAH Identity subtype of the AAA NAI extension, in > the registration request message [AAANAI] which is sent to the FA > every time the Mobile Node needs to re-authenticate. So, in the event > that the AMR generated by the FA is for a session that was previously > authorized, it MUST include the Destination-Host AVP, with the > identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent- > Host AVP with the identity and realm of the assigned HA found in the > HA-NAI. > > If the mobile node was successfully authenticated, the AAAH checks if > the home agent was located in the foreign realm, by checking Home- > Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other > AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- > Foreign-AAA AVP may also be used to verify the location of the home > agent. If the home agent is located in the foreign realm, then the > AAAH sends an HAR message to the home agent, which contains a MIP- > Reg-Request AVP. > > If the home agent was not located in the foreign realm, the AAAH > checks for the MIP-Home-Agent-Address AVP and if present the MIP- > Home-Agent-Host AVP. If one was specified, the AAAH checks that the > address is that of a known home agent and that the Mobile Node is > allowed to request this particular home agent, and that the home > agent's identity is included in the MIP-Home-Agent-Host AVP. If no > home agent was specified, and if the MIP-Feature-Vector has the Home- > Agent-Requested flag set, and if allowed by policy in the home realm, > the AAAH SHOULD allocate a home agent on behalf of the Mobile Node. > This can be done in a variety of ways, including using a load > balancing algorithm in order to keep the load on all home agents > equal. The actual algorithm used and the method of discovering the > home agents is outside the scope of this specification. > > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains > the Mobile IP Registration Request message data encapsulated in the > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The > AAAH MAY allocate a home address for the mobile node, while the Home > Agent MUST support home address allocation. In the event the AAAH > handles address allocation, it includes it in a MIP-Mobile-Node- > Address AVP within the HAR. The absence of this AVP informs the Home > Agent to perform the allocation. > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see Figure 2). If the > AAAH is session-stateful, it MUST send the same session identifier > for all HARs initiated on behalf of a given mobile node's session. > Otherwise, if the AAAH is session-stateless, it will manufacture a > unique session-id for every HAR. > > A mobile node's session is identified via its identity in the User- > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > AVPs. This is necessary in order to allow the session state machine, > defined in the base protocol [DIAMBASE], to be used unmodified with > this application. Therefore, an STR from a foreign agent would free > the session from the foreign agent, but not the one towards the home > agent (see figure 3). > > STR, Session-Id = foo STR, Session-Id = bar > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > STA, Session-Id = foo STA, Session-Id = bar > > Figure 3: Session Termination and Session Identifiers > > Upon receipt of the HAR, the home agent first processes the Diameter > message. The home agent processes the MIP-Reg-Request AVP and creates > the Registration Reply, encapsulating it within the MIP-Reg-Reply > AVP. In the creation of the Registration Reply the Home Agent must > include the HA NAI and the AAAH NAI, which will be created from the > Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is > needed, the home agent MUST also assign one and include the address > in both the Registration Reply and within the MIP-Mobile-Node-Address > AVP. > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > returned to the AAAH. > > Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > (AMA) message, includes the Accounting-Multi-Session-Id that was > present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node- > Address AVPs in the AMA message, enabling appropriate firewall > controls for the penetration of tunneled traffic between the Home > Agent and the Mobile Node. > > 1.3 Support for Mobile IP Handoffs > > Given the nature of Mobile IP, a mobile node MAY receive service from > many foreign agents during a period of time. However, the home realm > should not view these handoffs as different sessions, since this > could affect billing systems. Furthermore, many foreign agents do not > communicate, which makes it quite difficult for AAA information to be > exchanged between these entities. Therefore, it MUST be assumed that > a foreign agent is not aware that a registration request from a > mobile node has been previously authorized. > > A handoff registration request from a mobile node will cause an AMR > to be sent to its AAAF. The AMR will include a new session > identifier, and MAY be sent to an AAAF in the visited network other > than the AAAF, which received the previous AMR. However, with the > usage of the AAA NAI, this AMR is guaranteed to be received by the > AAAH to which the user is currently registered. > > Since the AAAH may be session-stateless, it is necessary for the > resulting HAR received by the HA to be identified as a continuation > of an existing session. If the HA receives an HAR for a mobile node, > with a new session identifier, and the HA can guarantee that this > request is to extend service for an existing service, then the HA > MUST be able to modify its internal session state information to > reflect the new session identifier. > > It is necessary for accounting records to have some commonality > across handoffs in order for correlation to occur. Therefore, the > home agent MUST send the same Accounting-Multi-Session-Id AVP value > in all HAAs for the mobile's session. That is, the HA generates a > unique Accounting-Multi-Session-Id when receiving an HAR for a new > session, and returns this same value in every HAA for the session. > This Accounting-Multi-Session-Id AVP will be returned to the foreign > agent by the AAAH in the AMA. Both the foreign and home agents MUST > include the Accounting-Multi-Session-Id in the accounting messages. > > ACR, Session-Id = foo ACR, Session-Id = bar > Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a > > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > > 1.4 Allocation of Home Agent in Foreign Network > > The Diameter Mobile IP application allows a home agent to be > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > When a foreign agent detects that the mobile node has a home agent > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > Request message, it MUST add a MIP-Feature-Vector AVP with the Home- > Agent- Requested flag set to one. If the home agent address is equal > to 255.255.255.255, then the foreign agent also MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the Home-Agent-Requested > flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm > flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available > flag in the MIP-Feature-Vector AVP to inform the AAAH that it is > willing and able to assign a Home Agent for the Mobile Node. When > doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP > and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- > Agent-Host AVP contains the identity of the home agent that would be > assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > contains the identity of the AAAF. > > In the event that the mobile node has been previously authorized by > the AAAH and now needs to be re-authenticated, and requests to keep > the assigned home agent in the foreign network, the mobile node MUST > include the HA NAI and the AAAH NAI in the registration request to > the FA. Upon receipt, the FA will create the AMR including the MIP- > Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH > NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the > MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF > authorizes the use of the requested home agent, the AAAF MUST set the > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > When the AAAH receives an AMR message, it first checks the > authentication data supplied by the mobile node, according to the > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > to authorize the mobile node. If the AMR indicates that the AAAF has > offered to allocate a Home Agent for the mobile node, i.e. the > Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or > the AMR indicates that the AAAF has offered a previously allocated > Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- > Network is set in the MIP-Feature-Vector AVP, then the AAAH must > decide whether its local policy would allow the user to have a Home > Agent in the foreign network or to keep the Home Agent in the foreign > network. If so, and after checking authorization from the data in the > AMR message, the AAAH sends the HAR message to Home Agent by > including the Destination-Host AVP set to the value found in the > AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if > the HA has been previously allocated and authorized by the AAAH. If > the HA has not been previously allocated by the foreign domain, the > HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. > > The HAR sent by the AAAH back to the foreign realm with the > Destination-Host AVP set to the home agent's identity, may not > necessarily be received by the same AAAF, which sent the AMR. > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA > AVP from the AMR message to the HAR message. In cases when another > AAAF receives the HAR, the new AAAF will use the MIP-Originating- > Foreign-AAA AVP for policy decisions, such as determining if the FA- > HA Key should be encrypted or not. If on the other hand, the AAAH > local policy determines that the MN-HA Key and the MN-FA Key must be > encrypted and no security association is known to the home agent, the > AAAH SHOULD send the HAR to the originating AAAF by including the > Destination-Host AVP set to the value found in the AMR's MIP- > Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or > the MIP-Candidate-Home-Agent-Host AVP found in the AMR. It seems there will never be a security association between the AAAH and the foreign HA. Because when the AAAH wants to secure an MN-XX session key, the AAAH sets up an SA with the AAAF (according to the previous sentence), not the HA. So if this is true, you can strike the phrase "and no security association is known to the home agent" from the previous sentence. What do you think of the following thought: In the interest of reducing the number of round-trips, the AAAH never bothers to try to set up a DSA with an FA or HA. That is, the FA or HA isn't required to support CMS, while the AAAF is required to support CMS, so why waste a round trip on a likely DSA-rejection by the mobility agent? And so the rule for an HAR, when there is a foreign HA, is: - If the AAAH is not encrypting session keys, then the Destination-Host of the AAAH's HAR is the HA. - If the AAAH is encrypting session keys, then the Destination-Host of the AAAH's HAR is the AAAF hosting the HA, and the HAR carries an AVP with the HA's identity (either the MIP-Candidate-Home-Agent-Host AVP or the MIP-Home-Agent-Host AVP). If the above makes sense, then the previous paragraph of proposed text can be replaced by the following: "If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key must be encrypted, the AAAH sends the HAR to the originating AAAF by including the Destination-Host AVP set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and copying the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR. If necessary, the AAAH first sets up a DSA with the originating AAAF. "If the AAAH's local policy determines that no keys need to be encrypted, then the HAR is sent by the AAAH back to the foreign realm with the Destination-Host AVP set to the home agent's identity. This HAR may not necessarily be received by the same AAAF which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, the new AAAF will use the MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not." > > Visited Home > Realm Realm > +--------+ ------- AMR -------> +--------+ > | AAAF | <------ HAR -------- | AAAH | > | | | | > +--->| server | ------- HAA -------> | server | > | +--------+ <------ AMA -------- +--------+ > | ^ | > | | | > HAR/HAA | AMR | | AMA > v | v > +---------+ +---------+ > | Home | | Foreign | > | Agent | | Agent | > +---------+ +---------+ > ^ > +--------+ | > | Mobile |<----------+ > | Node | Mobile IP > +--------+ > > Figure 5: Home Agent allocated in Visited Realm > > Upon receipt of a HAA from the Home Agent in the visited realm, the > AAAF forwards the HAA to the AAAH in the home realm. The AMA is then > constructed, and issued to the AAAF, and finally to the FA. If the > Result-Code indicates success, the HAA and AMA MUST include the MIP- > Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > Mobile Node Foreign Agent Home Agent AAAF AAAH > ----------- ------------- ------------- ---------- ---------- > > <----Challenge---- > Reg-Req (Response)-> > ------------AMR-------------> > -----AMR----> > <----HAR----- > <-----HAR------ > ------HAA------> > -----HAA----> > <----AMA----- > <-------------AMA------------ > <---Reg-Reply---- > Figure 6: Mobile IP/Diameter Message Exchange > > If the Mobile Node moves to another Foreign Network, it MAY either > request to keep the same Home Agent within the old foreign network, > or request to get a new one in the new foreign network. If the AAAH > is willing to provide the requested service, the mobile node will > have to be serviced by two AAAFs. > > Figure 7 shows the message flows for a mobile node requesting to keep > the home agent assigned in foreign network 1 when it moves to foreign > network 2. Upon reception of the AMR in Foreign network 2, the AAAF > follows the procedures described earlier and forwards AMR to the > mobile node's home network, i.e. its AAAH. If the mobile node was > successfully authenticated, the AAAH checks the identity of the > foreign and home agent to determine whether the user is in a third > realm. If this is the case, the AAAH must check whether the mobile is > still permitted to use the previously assigned home agent. > > > +---------------+ +---------------+ +-------------+ > |Foreign net 2 | |Foreign net 1 | |Home network | > | | | | | | > Mobile Node | FA AAAF | | HA AAAF | | AAAH | > ----------- | ---- ---- | | ---- ------ | | ------ | > +---------------+ +---------------+ +-------------+ > > <----Challenge---- > Reg-Req (Response)-> > ---AMR---> > ----------------AMR---------------> > <-----HAR----- > <---HAR---- > ----HAA---> > ------HAA----> > <---------------AMA---------------- > <--AMA---- > <----Reg-Reply----- > Figure 7: Request to access Home Agent from new Foreign Network > > If the mobile node is allowed to keep the home agent the AAAH then > sends a HAR, which contains the Mobile IP Registration Request > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > Home-Agent-Address AVP with home agent address, as well as any > optional KDC session keys, to the AAAF in foreign network 1. > Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA > AVP from AMR and include it in the HAR when a third foreign domain is > involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP > for policy decisions, such as determining if the FA-HA Key should be > encrypted or not. Upon reception the AAAF in foreign network 1 will > forward the HAR to the Home Agent if its local policy allows such > service. If the AAAF does not permit such service, it MUST return a > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > If the AAAH local policy determines that the MN-HA Key must be > encrypted and no security association is known to the home agent, the > AAAH MUST send the HAR to the AAAF in foreign network 1, which > originally assigned the HA in foreign network 1, by including its > identity in the Destination-Host AVP. Here is where I am still a bit confused. If the AAAH is session-stateful, then the AAAH can retrieve the destination AAAF's (in the first visited network) identity & realm from his state information, and send the HAR with a Destination-Host AVP with a value set to this destination AAAF's identity. But if the AAAH is not session-stateful, then how does the AAAH know the destination AAAF's identity? I asked this question is an earlier email (04-April), and you commented that "the AAAH can be session stateless using some back-ended mechanism, which is beyond the scope of this protocol, to retrieve necessary info." But I didn't understand your comment; can you flesh it out a bit more for me? I suppose that the AAAH could be session-stateless, but maintain a cache of his existing SAs with AAAFs, and include the { foreign HA identity, hosting AAAF identity } pairs as part of this cache. If so, then the AAAH would likely know the destination AAAF's identity, because the AAAH would *likely* have set up a DSA with this AAAF back when the MN was in the first-visited foreign network, so the AAAH would likely find a { foreign HA identity, hosting AAAF identity } match in his cache for the targeted HA. > > When the AAAF receives a HAA, the AAAF will forward the HAA back to > the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- > Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send > back an AMA to the AAAF in foreign network 2. > > If the old Foreign Network does not permit the use of its Home Agent > when the Mobile Node moves to a new foreign network, the AAAH or AAAF > MUST return an AMA with the Result-Code AVP set to > DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the > Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile > Node with an appropriate error. The Mobile Node MAY attempt to > request that a new Home Agent and Address be allocated. When the AAAH > transmits such an error, it MUST issue a Diameter Abort-Session- > Request message to the Home Agent to enable it to release any > resources. > > > .... > > 2.1 AA-Mobile-Node-Request > > .... > > > The foreign agent (or home agent in the case of a co-located > mobile mode)uses information found in the Registration > Request to construct the following AVPs that are to be > included as part of the AMR: > > .... > > home agent NAI (MIP-Home-Agent-Host AVP) > home AAA server NAI (Destination-Host AVP [DIAMBASE]) > > ... > > If the mobile node includes the home agent NAI and the home AAA > server NAI [AAANAI], the foreign agent MUST include the MIP-Home- > Agent-Host AVP and the Destination-Host AVP in the AMR. > > Message Format > > ::= < Diameter Header: 260, REQ, PXY > > < Session-ID > > { Auth-Application-Id } > { User-Name } > { Destination-Realm } > { Origin-Host } > { Origin-Realm } > { MIP-Reg-Request } > { MIP-MN-AAA-Auth } > [ Destination-Host ] > [ Origin-State-Id ] > [ MIP-Mobile-Node-Address ] > [ MIP-Home-Agent-Address ] > [ MIP-Home-Agent-Host] > [ MIP-Feature-Vector ] > [ MIP-Originating-Foreign-AAA ] > [ Authorization-Lifetime ] > [ Auth-Session-State ] > [ MIP-FA-Challenge ] > [ MIP-Candidate-Home-Agent-Host ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > .... > > 4.12 MIP-Home-Agent-Host AVP > > The MIP-Home-Agent-Host AVP (AVP Code TBD) if of type Grouped, and > contains the identity of the assigned Home Agent. If present in > the AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. > > MIP-Home-Agent-Host ::= < AVP Header: TBD > > { Destination-Realm } > { Destination-Host } > * [ AVP ] > > > .... > > > 5.3 Distributing the Mobile-Home Session Key > > .... > > If, on the other hand, the home agent is to be allocated in the > visited realm, the AAAH transmits the HAR to the foreign home agent, > where, prior to delivery to the home agent, it is perused by the AAAF > hosting the home agent. If the session key needs to be encrypted the > AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data > AVP using the security association with the home agent or with the > AAAF associated with the home agent. If no security association is > known the home agent, the AAAH will check if a security association > can be established using DSA messages defined in the CMS application > [CMS] with the originating host found in the MIP-Originating-Foreign- > AAA AVP and if the DSA establishment is successful, the AAAH will > encrypt the MIP-HA-to-MN Key AVP with the established security > association. On the other hand, if no security association exists and > the DSA establishment fails, the AAAH MUST return a Result-Code AVP > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If you go with the idea of reducing round-trips by not attempting to set up a DSA with the FA, then the above paragraph should be slightly revised. > > .... > > 11.1 Normative > > .... > > [AAANAI] F.Johansson, T.Johansson, "AAA NAI for Mobile IPv4 Exten­ > sion", draft-johansson-mip-aaa-nai-01.txt, IETF work in > progress, September 2002. Replace "September 2002" by "March 2002" (?). > [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response > Extensions". RFC 3012. November 2000. > > .... > > 11.2 Informative > > .... > > [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security > Application", draft-ietf-aaa-diameter-cms-sec-05.txt, > IETF work in progress, November 2001. Replace "November 2001" by "April 2002" (?). > .... > From owner-aaa-wg@merit.edu Wed Apr 10 11:11:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21839 for ; Wed, 10 Apr 2002 11:11:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D18D9912DD; Wed, 10 Apr 2002 11:11:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96F43912DF; Wed, 10 Apr 2002 11:11:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37CF8912DD for ; Wed, 10 Apr 2002 11:11:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 212665DDA8; Wed, 10 Apr 2002 11:11:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 78B4C5DDCA for ; Wed, 10 Apr 2002 11:11:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3AERGO27987; Wed, 10 Apr 2002 07:27:16 -0700 Date: Wed, 10 Apr 2002 07:27:16 -0700 (PDT) From: Bernard Aboba To: Johan Johansson Cc: aaa-wg , Sivasundar Ramamurthy Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's security association with the F In-Reply-To: <3CB04D5A.4030900@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #326. On Sun, 7 Apr 2002, Johan Johansson wrote: > Issue: HA can not know which ip address to store keys on > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: draft-mip-9 > Comment type: Technical > Priority: S > Section: 4.8 > > This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. > > The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from. > > If we as stated in section 4.8 simply copy the value of FA-Host from the Origin-Host field of the incoming AMR and then perform a DNS lookup, which in itself is unattractive, we may at best be able to choose a Diameter interface. If we assume that the CoA address in the reg request is the one to use we are choosing the tunneling interface where a raw mobile ip client would have access to the "real" ip address. > > It seems that raw MobileIP doesn't handle this case deterministically either and thus probably is a source of interopability problems in MobileIP as well. That discussion will be taken with the MobileIP wg. > > In any case we can solve the problem within Diameter without relying on the resolution within MobileIP by making the foreign agent include the proper ip address in the AMR to be forwarded to the home agent. We should probably also revamp the FA-Host avp to be an FA-Address AVP. > > Request changes: > > Change > > "4.8 MIP-Foreign-Agent-Host AVP > > The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type > DiameterIdentity and contains the identity of the foreign agent. This > AVP is copied from the value of the Origin-Host AVP in the AMR." > > to > > "4.8 MIP-Foreign-Agent-Address AVP > > The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type > IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MUST be added by the FA to all AMRs it sends and MUST be copied to the HAR sent by the AAAH." > > We *could* make it optional if we could agree on a reasonable default interface. My best guess for that would be MIP tunneling interface, in which case we could go with > > "4.8 MIP-Foreign-Agent-Address AVP > > The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type > IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MAY added by the FA to AMRs it sends and if present the AAAH MUST copy it to the HAR it sends. If the AVP is not present the HA MAY assume that the care-of-address of the mobile node should be used for its security association with the FA. If the FA requires co-located mobile nodes to register with it the MIP-Foreign-Agent-Address AVP MUST be added to all AMRs." > > Of course occurence tables and ABNFs should be updated too. > > j > > From owner-aaa-wg@merit.edu Wed Apr 10 11:16:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21981 for ; Wed, 10 Apr 2002 11:16:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BF5D912DF; Wed, 10 Apr 2002 11:16:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2DD8912E1; Wed, 10 Apr 2002 11:16:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 398A0912DF for ; Wed, 10 Apr 2002 11:16:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 142505DDC8; Wed, 10 Apr 2002 11:16:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 81B295DDA8 for ; Wed, 10 Apr 2002 11:16:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3AEWIN28234; Wed, 10 Apr 2002 07:32:18 -0700 Date: Wed, 10 Apr 2002 07:32:18 -0700 (PDT) From: Bernard Aboba To: Johan Johansson Cc: aaa-wg Subject: Re: [AAA-WG]: Suggestion about hierarchical realms a poor one In-Reply-To: <3CB0964C.3020900@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #328. On Sun, 7 Apr 2002, Johan Johansson wrote: > Issue: Suggestion about hierarchical realms a poor one > Submitter name: Johan Johansson > Submitter email address:johanj@ipunplugged.com > Date first submitted: 04-09-2002 > Reference: > Document: draft-base-10-2 > Comment type: Technical > Priority: 1 > Section: 6.1 > > Rationale: > > The suggestion is that > > > For routing of Diameter messages to work within an administrative > domain, all Diameter nodes within the realm MUST be peers. If > intermediate nodes are desired (see Figure 5), the destination node > MUST be in a subrealm and routes to that subrealm MUST exist in the > routing table on the sending node and all intermediate nodes. Figure > 5 shows an example of a hierarchical network that requires the use of > subrealms. In such a network, routing must be performed with longest > match from right. > > Figure 5 then goes on to describe a realm abc.com with e.g. a subrealm > called eng.abc.com and a relay node in between. It may not be obvious > from the draft, but the original example discussed that motivated this > text and figure in the first place as within the context of the mobile > ip application where there was a home server in the containing realm > abc.com and the home agents within the respective subrealms. > > Assume that there is a user called john.doe@eng.abc.com whose AMR is > handled by the server aaah.abc.com. This is a centralized home server > that serves the entire realm abc.com and therefore it has a route for > abc.com that on longest match from right has a LOCAL_ACTION entry. > Unfortunately this will never be selected since it must have a route to > eng.abc.com in order to send the HAR to the home agent, which means that > the AMR will arrive at a very surprised home agent. > > Requested change: > > Given the time constraints my suggestion is to fumble the issue and > remove all mention of it from the document. Route configuration and > network topology, within the context of the Mobile IP Diameter > application at least, is a surprisingly non-intuitive topic. > > j > > > > > > > > From owner-aaa-wg@merit.edu Wed Apr 10 11:18:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22006 for ; Wed, 10 Apr 2002 11:18:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8048912E1; Wed, 10 Apr 2002 11:16:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D6A4912E2; Wed, 10 Apr 2002 11:16:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 126F7912E1 for ; Wed, 10 Apr 2002 11:16:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF18B5DDCA; Wed, 10 Apr 2002 11:16:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7630F5DDC8 for ; Wed, 10 Apr 2002 11:16:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3AEWbN28262; Wed, 10 Apr 2002 07:32:37 -0700 Date: Wed, 10 Apr 2002 07:32:36 -0700 (PDT) From: Bernard Aboba To: Johan Johansson Cc: aaa-wg Subject: Re: [AAA-WG]: Message routing and vendor specific applications In-Reply-To: <3CB0670B.80508@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #327. On Sun, 7 Apr 2002, Johan Johansson wrote: > Issue: Message routing and vendor specific applications > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 04-07-2002 > Reference: > Document: Base > Comment type: Technical > Priority: S > Section: 2.7, 6.1, 6.1.6, 6.10, 9.7.1 > From owner-aaa-wg@merit.edu Wed Apr 10 11:25:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22173 for ; Wed, 10 Apr 2002 11:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E460D912E2; Wed, 10 Apr 2002 11:22:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3F4F912E6; Wed, 10 Apr 2002 11:22:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 377C8912E2 for ; Wed, 10 Apr 2002 11:22:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1891F5DDCA; Wed, 10 Apr 2002 11:22:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 794F45DDC8 for ; Wed, 10 Apr 2002 11:22:29 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020410152227.BAHH25793.fep02-svc.swip.net@ipunplugged.com>; Wed, 10 Apr 2002 17:22:27 +0200 Message-ID: <3CB4751D.3050407@ipunplugged.com> Date: Wed, 10 Apr 2002 17:23:41 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Sivasundar Ramamurthy , aaa-wg Subject: Re: [AAA-WG]: HA can not know which ip address to use for it'ssecurity association with the FA References: <3CB39850.CD587982@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >>>As you state above this is not obvious in RFC3220. So, I strongly >>>suggest that people that really believe that this is needed first >>>gets this clarified in the mobile ip wg. I would hate to see that >>>we try to add functionality that may not really be ok according to >>>mobile ip and RFC3220. >>> >>RFC3220 allows registering with the FA using a co-located address (R >>bit set in advertisement). This is a scenario where the COA (tunnel >>endpoint) is not the address of the FA's control interface. >> >I'm sorry but really don't understand what you try to arguing here. > >A "co-located care-of address" is a care-of address acquired by the >mobile node as a local IP address through some external >means, which the mobile node then associates with one of it own network >interfaces. The mode of using a co-located care-of address has the >advantage that it allows a mobile node to function without a foreign >agent, for example, in networks that have not yet deployed a foreign >agent. > >The R bit set in the advertisement, which you refer to above, tells the >MN that registration with a foreign agent is required even when using a >co-located care-of address. > >So, why would this R-bit have anything to do with allowing a mip control >interface and a mip tunneling interface?! > The FA forwards the request if you register with the FA, which means that the source ip address of the UDP packet sent to the HA will have the ip of the FA's mip control interface. The tunneling interface is of course the CoA, in this case the address that the MN got on the local network. It is unlikely that this will be the same as that of the FA's mip control interface. j From owner-aaa-wg@merit.edu Wed Apr 10 11:27:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22288 for ; Wed, 10 Apr 2002 11:27:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39535912E3; Wed, 10 Apr 2002 11:27:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0361D912E5; Wed, 10 Apr 2002 11:27:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8FC4912E3 for ; Wed, 10 Apr 2002 11:27:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6D235DDC8; Wed, 10 Apr 2002 11:27:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id 351BC5DDA8 for ; Wed, 10 Apr 2002 11:27:25 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep04-svc.swip.net with ESMTP id <20020410152723.ZRM16729.fep04-svc.swip.net@ipunplugged.com>; Wed, 10 Apr 2002 17:27:23 +0200 Message-ID: <3CB47645.8090405@ipunplugged.com> Date: Wed, 10 Apr 2002 17:28:37 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Johan Johansson Cc: john.loughney@nokia.com, aaa-wg Subject: Re: [AAA-WG]: Message routing and vendor specific applications References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E14@esebe004.NOE.Nokia.com> <3CB19DC4.3050000@ipunplugged.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please, someone comment on this one. I am reluctant to make a change that nobody has reviewed. j Johan Johansson wrote: > Sure. I just want to get the issue reviewed first to make sure I am > not seeing a problem where there is none and then I'd want to see some > reaction to the solution alternatives I have suggested. > > j > > john.loughney@nokia.com wrote: > >> Johan, >> >> Do you want to supply the text? >> >> >> John >> >>> -----Original Message----- >>> From: ext Johan Johansson [mailto:johanj@ipunplugged.com] >>> Sent: 07 April, 2002 18:35 >>> To: aaa-wg >>> Subject: [AAA-WG]: Message routing and vendor specific applications >>> >>> >>> Issue: Message routing and vendor specific >>> applications >>> Submitter name: Johan Johansson >>> Submitter email address: johanj@ipunplugged.com >>> Date first submitted: 04-07-2002 Reference: >>> Document: Base Comment type: Technical >>> Priority: S Section: 2.7, 6.1, 6.1.6, 6.10, >>> 9.7.1 >>> >>> Rationale/Explanation of issue: >>> >>> We allow vendor specific applications with their own "namespaces" >>> but we do not perform routing on them. Section 6.1.6 simply states: >>> >>> Diameter request message routing is done via realms. A Diameter >>> message that is able to be proxied MUST include the target realm in >>> the Destination-Realm AVP. The realm MAY be retrieved from the User- >>> Name AVP, which is in the form of a Network Access Identifier (NAI). >>> The realm portion of the NAI is inserted in the Destination-Realm >>> AVP. >>> >>> Diameter agents MAY have a list of locally supported realms, and MAY >>> have a list of externally supported realms. When a request is >>> received that includes a realm that is not locally supported, the >>> message is routed to the peer configured in the Realm Routing Table >>> table (see section 2.8). >>> >>> On a side note this should probably be section 2.7, but the >>> important part is that nowhere in these paragraphs is >>> per-application routing mentioned, let alone vendor-specific such. >>> >>> The preceding section 6.1 states >>> >>> The Destination-Realm AVP MUST be present if the message is >>> proxiable. Proxiable request messages MUST also contain either an >>> Acct-Application-Id AVP or an Auth-Application-Id AVP. >>> >>> while 9.7.1 happily claims >>> >>> One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs >>> MUST be present. If the Vendor-Specific-Application-Id grouped AVP is >>> present, it must have an Acct-Application-Id inside. >>> >>> Pretty contradictory if you ask me. >>> >>> Finally, the section 2.7 describing the realm based routing table says >>> >>> >>> - Application Identifier. A route entry can have a different >>> destination based on the Acct-Application-Id for accounting >>> messages) or Auth-Application-Id (for non-accounting messages) >>> of the message. This field MUST be used as a secondary key field >>> in routing table lookups. >>> >>> It seems to me that it would need to use vendor id *and* application >>> id to perform a proper lookup. >>> >>> Requested change: >>> >>> The solution is conceptually simple: make the routing table store >>> vendor id and application id and add text to 6.1.6 to take these >>> into account when routing requests. >>> >>> We now have two ways to identify the application of a request. >>> Either it has a "naked" Acct/Auth-Application-Id *or* it has a >>> grouped Vendor-Specific-Application-Id AVP where the Vendor-Id is >>> non-zero. Granted, the Diameter standard vendor is an important >>> special case but is it important enough to require a two-stage lookup? >>> >>> What do you think? >>> >>> I'll sneak in an editorial side-issue. Shouldn't we change >>> >>> >>> 6.10 Vendor-Specific-Application-Id AVP >>> >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >>> Grouped and is used to advertise support of a vendor-specific >>> Diameter Application. Either the Auth-Application-Id or the Acct- >>> Application-Id AVP MAY be present. Exactly one of the Auth- >>> Application-Id and Acct-Application-Id AVPs MAY be present. >>> >>> to >>> >>> 6.10 Vendor-Specific-Application-Id AVP >>> >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type >>> Grouped and is used to advertise support of a vendor-specific >>> Diameter Application. Exactly one of the Auth- >>> Application-Id and Acct-Application-Id AVPs MUST be present. >>> >>> j >>> >>> >> > > > From owner-aaa-wg@merit.edu Wed Apr 10 11:28:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22314 for ; Wed, 10 Apr 2002 11:27:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C40A9131A; Wed, 10 Apr 2002 11:27:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23D1791318; Wed, 10 Apr 2002 11:27:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D0C3912E5 for ; Wed, 10 Apr 2002 11:27:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F00785DDC8; Wed, 10 Apr 2002 11:27:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 833C25DDA8 for ; Wed, 10 Apr 2002 11:27:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3AEhfb28827; Wed, 10 Apr 2002 07:43:41 -0700 Date: Wed, 10 Apr 2002 07:43:41 -0700 (PDT) From: Bernard Aboba To: bglee@etri.re.kr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Minor corrections/clarifications to base-10 about Failed-AVP. In-Reply-To: <8470181DABD5D511B3E700D0B7A8AC4A946145@cms3.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue #329. On Tue, 9 Apr 2002 bglee@etri.re.kr wrote: > Issue : Minor corrections/clarifications to base-10 about > Failed-AVP > Submitter name: BG Lee > Submitter email address: bglee@etri.re.kr > Date first submitted: 04-9-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: ? > Section: 7.5 Failed-AVP AVP From owner-aaa-wg@merit.edu Wed Apr 10 11:37:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22521 for ; Wed, 10 Apr 2002 11:37:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC8DE912E6; Wed, 10 Apr 2002 11:36:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 823A1912E7; Wed, 10 Apr 2002 11:36:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C260912E6 for ; Wed, 10 Apr 2002 11:36:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52AFA5DDC8; Wed, 10 Apr 2002 11:36:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id B402D5DDA8 for ; Wed, 10 Apr 2002 11:36:43 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep04-svc.swip.net with ESMTP id <20020410153641.BAMP16729.fep04-svc.swip.net@ipunplugged.com>; Wed, 10 Apr 2002 17:36:41 +0200 Message-ID: <3CB47873.3080307@ipunplugged.com> Date: Wed, 10 Apr 2002 17:37:55 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >> >> If the mobile node is allowed to keep the home agent the AAAH then >> sends a HAR, which contains the Mobile IP Registration Request >> message data encapsulated in the MIP-Reg-Request AVP and the MIP- >> Home-Agent-Address AVP with home agent address, as well as any >> optional KDC session keys, to the AAAF in foreign network 1. >> Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA >> AVP from AMR and include it in the HAR when a third foreign domain is >> involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP >> for policy decisions, such as determining if the FA-HA Key should be >> encrypted or not. Upon reception the AAAF in foreign network 1 will >> forward the HAR to the Home Agent if its local policy allows such >> service. If the AAAF does not permit such service, it MUST return a >> DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. >> >> If the AAAH local policy determines that the MN-HA Key must be >> encrypted and no security association is known to the home agent, the >> AAAH MUST send the HAR to the AAAF in foreign network 1, which >> originally assigned the HA in foreign network 1, by including its >> identity in the Destination-Host AVP. >> > >Here is where I am still a bit confused. > >If the AAAH is session-stateful, then the AAAH can retrieve the >destination AAAF's (in the first visited network) identity & realm >from his state information, and send the HAR with a Destination-Host >AVP with a value set to this destination AAAF's identity. > >But if the AAAH is not session-stateful, then how does the AAAH know >the destination AAAF's identity? I asked this question is an earlier >email (04-April), and you commented that "the AAAH can be session >stateless using some back-ended mechanism, which is beyond the scope >of this protocol, to retrieve necessary info." But I didn't understand >your comment; can you flesh it out a bit more for me? > >I suppose that the AAAH could be session-stateless, but maintain a >cache of his existing SAs with AAAFs, and include the { foreign HA >identity, hosting AAAF identity } pairs as part of this cache. If so, >then the AAAH would likely know the destination AAAF's identity, >because the AAAH would *likely* have set up a DSA with this AAAF back >when the MN was in the first-visited foreign network, so the AAAH >would likely find a { foreign HA identity, hosting AAAF identity } >match in his cache for the targeted HA. > I still haven't received any answer to why we don't pass around the identity of the AAAF if that is what we are after in the first place instead of the AAAH. The AAAF can be retrieved from the appropriate AVP and placed in a GNAI extension instead of the AAAH's identity. If this is echoed back each time the problem is solved, right?`Since there is no real reason for the AAAH to stay the same across handovers we end up doing less work in total by removing the use of the AAAH GNAI. j From owner-aaa-wg@merit.edu Wed Apr 10 13:27:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25961 for ; Wed, 10 Apr 2002 13:27:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D250C91223; Wed, 10 Apr 2002 13:27:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E5DD912ED; Wed, 10 Apr 2002 13:27:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BD0591223 for ; Wed, 10 Apr 2002 13:27:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E3C55DDCC; Wed, 10 Apr 2002 13:27:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 1CBCB5DDCA for ; Wed, 10 Apr 2002 13:27:11 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id NAA05950 for ; Wed, 10 Apr 2002 13:27:44 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id NAA07352 for ; Wed, 10 Apr 2002 13:29:29 -0400 (EDT) From: "Mark Jones" To: "aaa-wg" Subject: RE: [AAA-WG]: Message routing and vendor specific applications Date: Wed, 10 Apr 2002 13:29:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CB47645.8090405@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, I agree that message routing as described in the latest draft does not take into account vendor-specific applications. If I've correctly understood the requested change, the Vendor-Id field would be added to the Realm Routing Table Entry and if the Application-Id field contains the identifier of a IETF standard application, the Vendor-ID field MUST be set to zero (0). I also agree with the change suggested in your editorial side-issue. Regards, Mark > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Johan Johansson > Sent: April 10, 2002 1:29 PM > To: Johan Johansson > Cc: john.loughney@nokia.com; aaa-wg > Subject: Re: [AAA-WG]: Message routing and vendor specific applications > > > Please, someone comment on this one. I am reluctant to make a change > that nobody has reviewed. > > j > > Johan Johansson wrote: > > > Sure. I just want to get the issue reviewed first to make sure I am > > not seeing a problem where there is none and then I'd want to see some > > reaction to the solution alternatives I have suggested. > > > > j > > > > john.loughney@nokia.com wrote: > > > >> Johan, > >> > >> Do you want to supply the text? > >> > >> > >> John > >> > >>> -----Original Message----- > >>> From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > >>> Sent: 07 April, 2002 18:35 > >>> To: aaa-wg > >>> Subject: [AAA-WG]: Message routing and vendor specific applications > >>> > >>> > >>> Issue: Message routing and vendor specific > >>> applications > >>> Submitter name: Johan Johansson > >>> Submitter email address: johanj@ipunplugged.com > >>> Date first submitted: 04-07-2002 Reference: > >>> Document: Base Comment type: Technical > >>> Priority: S Section: 2.7, 6.1, 6.1.6, 6.10, > >>> 9.7.1 > >>> > >>> Rationale/Explanation of issue: > >>> > >>> We allow vendor specific applications with their own "namespaces" > >>> but we do not perform routing on them. Section 6.1.6 simply states: > >>> > >>> Diameter request message routing is done via realms. A Diameter > >>> message that is able to be proxied MUST include the target realm in > >>> the Destination-Realm AVP. The realm MAY be retrieved from the User- > >>> Name AVP, which is in the form of a Network Access Identifier (NAI). > >>> The realm portion of the NAI is inserted in the Destination-Realm > >>> AVP. > >>> > >>> Diameter agents MAY have a list of locally supported realms, and MAY > >>> have a list of externally supported realms. When a request is > >>> received that includes a realm that is not locally supported, the > >>> message is routed to the peer configured in the Realm Routing Table > >>> table (see section 2.8). > >>> > >>> On a side note this should probably be section 2.7, but the > >>> important part is that nowhere in these paragraphs is > >>> per-application routing mentioned, let alone vendor-specific such. > >>> > >>> The preceding section 6.1 states > >>> > >>> The Destination-Realm AVP MUST be present if the message is > >>> proxiable. Proxiable request messages MUST also contain either an > >>> Acct-Application-Id AVP or an Auth-Application-Id AVP. > >>> > >>> while 9.7.1 happily claims > >>> > >>> One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > >>> MUST be present. If the Vendor-Specific-Application-Id > grouped AVP is > >>> present, it must have an Acct-Application-Id inside. > >>> > >>> Pretty contradictory if you ask me. > >>> > >>> Finally, the section 2.7 describing the realm based routing table says > >>> > >>> > >>> - Application Identifier. A route entry can have a different > >>> destination based on the Acct-Application-Id for accounting > >>> messages) or Auth-Application-Id (for non-accounting messages) > >>> of the message. This field MUST be used as a secondary > key field > >>> in routing table lookups. > >>> > >>> It seems to me that it would need to use vendor id *and* application > >>> id to perform a proper lookup. > >>> > >>> Requested change: > >>> > >>> The solution is conceptually simple: make the routing table store > >>> vendor id and application id and add text to 6.1.6 to take these > >>> into account when routing requests. > >>> > >>> We now have two ways to identify the application of a request. > >>> Either it has a "naked" Acct/Auth-Application-Id *or* it has a > >>> grouped Vendor-Specific-Application-Id AVP where the Vendor-Id is > >>> non-zero. Granted, the Diameter standard vendor is an important > >>> special case but is it important enough to require a two-stage lookup? > >>> > >>> What do you think? > >>> > >>> I'll sneak in an editorial side-issue. Shouldn't we change > >>> > >>> > >>> 6.10 Vendor-Specific-Application-Id AVP > >>> > >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > >>> Grouped and is used to advertise support of a vendor-specific > >>> Diameter Application. Either the Auth-Application-Id or the Acct- > >>> Application-Id AVP MAY be present. Exactly one of the Auth- > >>> Application-Id and Acct-Application-Id AVPs MAY be present. > >>> > >>> to > >>> > >>> 6.10 Vendor-Specific-Application-Id AVP > >>> > >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > >>> Grouped and is used to advertise support of a vendor-specific > >>> Diameter Application. Exactly one of the Auth- > >>> Application-Id and Acct-Application-Id AVPs MUST be present. > >>> > >>> j > >>> > >>> > >> > > > > > > > > > > From owner-aaa-wg@merit.edu Wed Apr 10 17:58:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03624 for ; Wed, 10 Apr 2002 17:58:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADD2491324; Wed, 10 Apr 2002 17:58:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D34B91327; Wed, 10 Apr 2002 17:58:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BA3F91324 for ; Wed, 10 Apr 2002 17:58:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61E575DE11; Wed, 10 Apr 2002 17:58:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 441FB5DD9B for ; Wed, 10 Apr 2002 17:58:43 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id 403A8600EF1 for ; Wed, 10 Apr 2002 14:58:39 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id OAA17857 for ; Wed, 10 Apr 2002 14:59:32 -0700 (PDT) Date: Wed, 10 Apr 2002 14:59:30 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: [AAA-WG]: [ISSUE] key lifetime Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter Name: Siva Ramamurthy Submitter email address: sivasundar_ramamurthy@hp.com Date first submitter: 3/27/2002 Document: Mobile IP Comment Type: T Priority: 1 Section: 1.6, 5.1, 6.13 Rationale/Explanation of Issue: Please bear with me for bringing this up again, for I dont want to regret later that I did not! As I understand the draft, session Termination at the mobility agents can be caused by two events: 1. MN not re-authorizing before the auth lifetime expires 2. Keys to the MN expiring Consider the scenario where the a MN is given keys for infite time (or a value many time bigger that the authentication time) and an authentication time of 300 secs. And during the course of roaming around, the MN at some point is not able to re-authenticate itself (no FA/co-located COA). This leads to termination of the session at the HA and any sessions maintained for this MN by FA(s). Sometime later, the MN does find that its way back to a previously visited FA and is able to register without the need for requesting keys (which are still alive). Since the MN does not include the MN-AAA auth ext, AAA cannot be used and thus no new session can be created for the MN. So the FA and HA provide services to the MN even while no session exists. I find nothing in the current standards that say that this is wrong or not permissible, which probably means that there is nothing special to handling this scenario and/or the standards provide the answers on what to do. Can the WG please verify this? Thanks for the consideration. regards, Siva From owner-aaa-wg@merit.edu Wed Apr 10 18:34:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04148 for ; Wed, 10 Apr 2002 18:34:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 570D09132E; Wed, 10 Apr 2002 18:34:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04F989132A; Wed, 10 Apr 2002 18:34:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93E03912F6 for ; Wed, 10 Apr 2002 18:33:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 722745DE0D; Wed, 10 Apr 2002 18:33:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 547895DDED for ; Wed, 10 Apr 2002 18:33:46 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel13.hp.com (Postfix) with ESMTP id B073440024E for ; Wed, 10 Apr 2002 15:33:45 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA18264; Wed, 10 Apr 2002 15:34:39 -0700 (PDT) Date: Wed, 10 Apr 2002 15:34:39 -0700 (PDT) From: Joe Lau Message-Id: <200204102234.PAA18264@strtio1.cup.hp.com> To: sramam@cup.hp.com Subject: Re: [AAA-WG]: [ISSUE] key lifetime In-Reply-To: Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Another point that I would like to bring to the table... The situation described here has deep implications on accounting which relies on having a live AAA session associated with the MN. Joe Lau > Submitter Name: Siva Ramamurthy > Submitter email address: sivasundar_ramamurthy@hp.com > Date first submitter: 3/27/2002 > Document: Mobile IP > Comment Type: T > Priority: 1 > Section: 1.6, 5.1, 6.13 > > Rationale/Explanation of Issue: > > Please bear with me for bringing this up again, for I dont want to > regret later that I did not! > > As I understand the draft, session Termination at the mobility agents > can be caused by two events: > > 1. MN not re-authorizing before the auth lifetime expires > > 2. Keys to the MN expiring > > Consider the scenario where the a MN is given keys for infite time (or > a value many time bigger that the authentication time) and an > authentication time of 300 secs. And during the course of roaming > around, the MN at some point is not able to re-authenticate itself (no > FA/co-located COA). This leads to termination of the session at the HA > and any sessions maintained for this MN by FA(s). Sometime later, the > MN does find that its way back to a previously visited FA and is able > to register without the need for requesting keys (which are still > alive). Since the MN does not include the MN-AAA auth ext, AAA cannot > be used and thus no new session can be created for the MN. So the FA > and HA provide services to the MN even while no session exists. > > I find nothing in the current standards that say that this is wrong or > not permissible, which probably means that there is nothing special to > handling this scenario and/or the standards provide the answers on > what to do. Can the WG please verify this? Thanks for the > consideration. > > > regards, > > Siva From owner-aaa-wg@merit.edu Wed Apr 10 22:55:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09597 for ; Wed, 10 Apr 2002 22:55:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D18E991226; Wed, 10 Apr 2002 22:55:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 957DA9132C; Wed, 10 Apr 2002 22:55:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C9E191226 for ; Wed, 10 Apr 2002 22:55:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 401D75DE5A; Wed, 10 Apr 2002 22:55:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 02D215DDD2 for ; Wed, 10 Apr 2002 22:55:01 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3B2sti16343; Wed, 10 Apr 2002 21:54:55 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3B2sta13370; Wed, 10 Apr 2002 21:54:55 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA26586; Wed, 10 Apr 2002 21:54:55 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA20655; Wed, 10 Apr 2002 21:54:54 -0500 (CDT) Message-ID: <3CB4FA49.A95CE72D@ericsson.com> Date: Wed, 10 Apr 2002 19:51:54 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Bob, Thanks a lot for your comments. Please find mine inline... /Tony Bob Kopacz wrote: > > > The HAR sent by the AAAH back to the foreign realm with the > > Destination-Host AVP set to the home agent's identity, may not > > necessarily be received by the same AAAF, which sent the AMR. > > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA > > AVP from the AMR message to the HAR message. In cases when another > > AAAF receives the HAR, the new AAAF will use the MIP-Originating- > > Foreign-AAA AVP for policy decisions, such as determining if the FA- > > HA Key should be encrypted or not. If on the other hand, the AAAH > > local policy determines that the MN-HA Key and the MN-FA Key must be > > encrypted and no security association is known to the home agent, the > > AAAH SHOULD send the HAR to the originating AAAF by including the > > Destination-Host AVP set to the value found in the AMR's MIP- > > Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or > > the MIP-Candidate-Home-Agent-Host AVP found in the AMR. > > It seems there will never be a security association between the AAAH and > the foreign HA. Because when the AAAH wants to secure an MN-XX > session key, the AAAH sets up an SA with the AAAF (according to the > previous sentence), not the HA. So if this is true, you can strike > the phrase "and no security association is known to the home agent" > from the previous sentence. > > What do you think of the following thought: In the interest of reducing > the number of round-trips, the AAAH never bothers to try to set up a DSA > with an FA or HA. That is, the FA or HA isn't required to support CMS, > while the AAAF is required to support CMS, so why waste a round trip on a > likely DSA-rejection by the mobility agent? Oh, I see the misunderstanding. I did mean to say the if you don't have an SA to the HA you should try to establish a DSA and most likely be rejected and waste an extra round trip. I only meant to say that if the AAAH don't have a pre configured SA with the HA then it should be done as you state below. > > > And so the rule for an HAR, when there is a foreign HA, is: > - If the AAAH is not encrypting session keys, then the Destination-Host of > the AAAH's HAR is the HA. > - If the AAAH is encrypting session keys, then the Destination-Host of the > AAAH's HAR is the AAAF hosting the HA, and the HAR carries an AVP with the > HA's identity (either the MIP-Candidate-Home-Agent-Host AVP or the > MIP-Home-Agent-Host AVP). > > If the above makes sense, then the previous paragraph of proposed text > can be replaced by the following: > > "If the AAAH's local policy determines that the MN-HA Key and/or the > MN-FA Key must be encrypted, the AAAH sends the HAR to the originating > AAAF by including the Destination-Host AVP set to the value found in > the AMR's MIP-Originating-Foreign-AAA AVP, and copying the > MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found > in the AMR. If necessary, the AAAH first sets up a DSA with the > originating AAAF. > > "If the AAAH's local policy determines that no keys need to be > encrypted, then the HAR is sent by the AAAH back to the foreign realm > with the Destination-Host AVP set to the home agent's identity. This > HAR may not necessarily be received by the same AAAF which sent the > AMR. Therefore the AAAH MUST always copy the > MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR > message. In cases when another AAAF receives the HAR, the new AAAF > will use the MIP-Originating-Foreign-AAA AVP for policy decisions, > such as determining if the FA-HA Key should be encrypted or not." So how about this: If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key must be encrypted and no pre-configured security association exists between the AAAH and the home agent, the AAAH sends the HAR to the originating AAAF. In this HAR the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into the HAR. If necessary, the AAAH first sets up a DSA with the originating AAAF. If no pre-configured security association exists between the AAAH and the home agent, the AAAH should not attempt to set up a DSA with the home agent, since mobility agents may not support CSM strong security. If the AAAH's local policy determines that no keys need to be encrypted or the keys need to be encrypted and a pre-configured security association exists between the AAAH and the home agent, the HAR is sent by the AAAH back to the foreign realm with the Destination-Host AVP set to the home agent's identity. This HAR may not necessarily be received by the same AAAF which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, this new AAAF will use the MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not. Does it make sense? > > > > > > Visited Home > > Realm Realm > > +--------+ ------- AMR -------> +--------+ > > | AAAF | <------ HAR -------- | AAAH | > > | | | | > > +--->| server | ------- HAA -------> | server | > > | +--------+ <------ AMA -------- +--------+ > > | ^ | > > | | | > > HAR/HAA | AMR | | AMA > > v | v > > +---------+ +---------+ > > | Home | | Foreign | > > | Agent | | Agent | > > +---------+ +---------+ > > ^ > > +--------+ | > > | Mobile |<----------+ > > | Node | Mobile IP > > +--------+ > > > > Figure 5: Home Agent allocated in Visited Realm > > > > Upon receipt of a HAA from the Home Agent in the visited realm, the > > AAAF forwards the HAA to the AAAH in the home realm. The AMA is then > > constructed, and issued to the AAAF, and finally to the FA. If the > > Result-Code indicates success, the HAA and AMA MUST include the MIP- > > Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > > > Mobile Node Foreign Agent Home Agent AAAF AAAH > > ----------- ------------- ------------- ---------- ---------- > > > > <----Challenge---- > > Reg-Req (Response)-> > > ------------AMR-------------> > > -----AMR----> > > <----HAR----- > > <-----HAR------ > > ------HAA------> > > -----HAA----> > > <----AMA----- > > <-------------AMA------------ > > <---Reg-Reply---- > > Figure 6: Mobile IP/Diameter Message Exchange > > > > If the Mobile Node moves to another Foreign Network, it MAY either > > request to keep the same Home Agent within the old foreign network, > > or request to get a new one in the new foreign network. If the AAAH > > is willing to provide the requested service, the mobile node will > > have to be serviced by two AAAFs. > > > > Figure 7 shows the message flows for a mobile node requesting to keep > > the home agent assigned in foreign network 1 when it moves to foreign > > network 2. Upon reception of the AMR in Foreign network 2, the AAAF > > follows the procedures described earlier and forwards AMR to the > > mobile node's home network, i.e. its AAAH. If the mobile node was > > successfully authenticated, the AAAH checks the identity of the > > foreign and home agent to determine whether the user is in a third > > realm. If this is the case, the AAAH must check whether the mobile is > > still permitted to use the previously assigned home agent. > > > > > > +---------------+ +---------------+ +-------------+ > > |Foreign net 2 | |Foreign net 1 | |Home network | > > | | | | | | > > Mobile Node | FA AAAF | | HA AAAF | | AAAH | > > ----------- | ---- ---- | | ---- ------ | | ------ | > > +---------------+ +---------------+ +-------------+ > > > > <----Challenge---- > > Reg-Req (Response)-> > > ---AMR---> > > ----------------AMR---------------> > > <-----HAR----- > > <---HAR---- > > ----HAA---> > > ------HAA----> > > <---------------AMA---------------- > > <--AMA---- > > <----Reg-Reply----- > > Figure 7: Request to access Home Agent from new Foreign Network > > > > If the mobile node is allowed to keep the home agent the AAAH then > > sends a HAR, which contains the Mobile IP Registration Request > > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > > Home-Agent-Address AVP with home agent address, as well as any > > optional KDC session keys, to the AAAF in foreign network 1. > > Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA > > AVP from AMR and include it in the HAR when a third foreign domain is > > involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP > > for policy decisions, such as determining if the FA-HA Key should be > > encrypted or not. Upon reception the AAAF in foreign network 1 will > > forward the HAR to the Home Agent if its local policy allows such > > service. If the AAAF does not permit such service, it MUST return a > > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > > > If the AAAH local policy determines that the MN-HA Key must be > > encrypted and no security association is known to the home agent, the > > AAAH MUST send the HAR to the AAAF in foreign network 1, which > > originally assigned the HA in foreign network 1, by including its > > identity in the Destination-Host AVP. > > Here is where I am still a bit confused. > > If the AAAH is session-stateful, then the AAAH can retrieve the > destination AAAF's (in the first visited network) identity & realm > from his state information, and send the HAR with a Destination-Host > AVP with a value set to this destination AAAF's identity. > > But if the AAAH is not session-stateful, then how does the AAAH know > the destination AAAF's identity? I asked this question is an earlier > email (04-April), and you commented that "the AAAH can be session > stateless using some back-ended mechanism, which is beyond the scope > of this protocol, to retrieve necessary info." But I didn't understand > your comment; can you flesh it out a bit more for me? I'm sorry if I was unclear . I meant the same as you state below without be to detailed :). Thus, if AAAH is session-stateless it could either cache the SAs as you describe below or the AAAH could use a "back-ended mechanism" like a database. However, I believe this is implementation specific and I don't think we have to specify a solution in the spec for this. > > > I suppose that the AAAH could be session-stateless, but maintain a > cache of his existing SAs with AAAFs, and include the { foreign HA > identity, hosting AAAF identity } pairs as part of this cache. If so, > then the AAAH would likely know the destination AAAF's identity, > because the AAAH would *likely* have set up a DSA with this AAAF back > when the MN was in the first-visited foreign network, so the AAAH > would likely find a { foreign HA identity, hosting AAAF identity } > match in his cache for the targeted HA. > > > > > > 5.3 Distributing the Mobile-Home Session Key > > > > .... > > > > If, on the other hand, the home agent is to be allocated in the > > visited realm, the AAAH transmits the HAR to the foreign home agent, > > where, prior to delivery to the home agent, it is perused by the AAAF > > hosting the home agent. If the session key needs to be encrypted the > > AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data > > AVP using the security association with the home agent or with the > > AAAF associated with the home agent. If no security association is > > known the home agent, the AAAH will check if a security association > > can be established using DSA messages defined in the CMS application > > [CMS] with the originating host found in the MIP-Originating-Foreign- > > AAA AVP and if the DSA establishment is successful, the AAAH will > > encrypt the MIP-HA-to-MN Key AVP with the established security > > association. On the other hand, if no security association exists and > > the DSA establishment fails, the AAAH MUST return a Result-Code AVP > > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > If you go with the idea of reducing round-trips by not attempting to > set up a DSA with the FA, then the above paragraph should be slightly > revised. So if my above changes is ok, how about this: If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent. If the session key needs to be encrypted the AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP in a CMS-Encrypted-Data AVP using the security association with the home agent or with the AAAF associated with the home agent. If no security association exists either between the AAAH and the home agent or between the AAAH and the AAAF associated with the home agent, the AAAH will check if a security association can be established, using DSA messages defined in the CMS application [CMS], with the AAAF associated with the home agent and if the DSA establishment is successful, the AAAH will encrypt the MIP-HA-to-MN Key AVP and MIP-FA-to-MN AVP with the established security association. On the other hand, if no security association exists and the DSA establishment fails, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > > > > > .... > > > > 11.1 Normative > > > > .... > > > > [AAANAI] F.Johansson, T.Johansson, "AAA NAI for Mobile IPv4 Exten­ > > sion", draft-johansson-mip-aaa-nai-01.txt, IETF work in > > progress, September 2002. > > Replace "September 2002" by "March 2002" (?). Check. > > > > [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response > > Extensions". RFC 3012. November 2000. > > > > .... > > > > 11.2 Informative > > > > .... > > > > [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security > > Application", draft-ietf-aaa-diameter-cms-sec-05.txt, > > IETF work in progress, November 2001. > > Replace "November 2001" by "April 2002" (?). Check. > > > > .... > > From owner-aaa-wg@merit.edu Wed Apr 10 23:22:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10167 for ; Wed, 10 Apr 2002 23:22:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B37A91330; Wed, 10 Apr 2002 23:21:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2283191331; Wed, 10 Apr 2002 23:21:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AC7991330 for ; Wed, 10 Apr 2002 23:21:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC8105DE45; Wed, 10 Apr 2002 23:21:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 38C875DE09 for ; Wed, 10 Apr 2002 23:21:48 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g3B3Me4b031519; Thu, 11 Apr 2002 05:22:52 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "Tony Johansson" Cc: "Johan Johansson" , "aaa-wg" Subject: RE: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA Date: Thu, 11 Apr 2002 05:19:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Sivasundar Ramamurthy >Sent: den 10 april 2002 02:11 >To: Tony Johansson >Cc: Johan Johansson; aaa-wg >Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's >security association with the FA > > > > >Hi Tony, > >> As you state above this is not obvious in RFC3220. So, I strongly >> suggest that people that really believe that this is needed first >> gets this clarified in the mobile ip wg. I would hate to see that >> we try to add functionality that may not really be ok according to >> mobile ip and RFC3220. > >RFC3220 allows registering with the FA using a co-located address (R >bit set in advertisement). This is a scenario where the COA (tunnel >endpoint) is not the address of the FA's control interface. But if you use co-located care of address, you will not use an SA between the CoA and HA, since the MN is already authenticated via the MN-HA Auth. Ext. /Fredrik > >thanks, > >Siva > > From owner-aaa-wg@merit.edu Wed Apr 10 23:56:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11005 for ; Wed, 10 Apr 2002 23:56:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5014B91333; Wed, 10 Apr 2002 23:56:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F6F791334; Wed, 10 Apr 2002 23:56:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C4D291333 for ; Wed, 10 Apr 2002 23:56:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22ADF5DE59; Wed, 10 Apr 2002 23:56:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AD8535DE58 for ; Wed, 10 Apr 2002 23:56:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3B3Cbr32600 for ; Wed, 10 Apr 2002 20:12:37 -0700 Date: Wed, 10 Apr 2002 20:12:37 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 330: Diameter should not require separate TLS port Submitter name: Allison Mankin Submitter email address: mankin@isi.edu Date first submitted: 04-10-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: S Section: 2.1 (contradicts section 13.3) Justification: The IESG is encouraging WGs to enable their applications to negotiate an upgrade to TLS rather than requiring a separate port. Diameter cannot yet handle this "startTLS" up-negotiation. Do not assume that Diameter will be granted an addition port for use with TLS. Change: Need support for TLS up-negotiation in Diameter. From owner-aaa-wg@merit.edu Thu Apr 11 00:11:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11207 for ; Thu, 11 Apr 2002 00:11:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC40991334; Thu, 11 Apr 2002 00:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7984F91335; Thu, 11 Apr 2002 00:11:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E58A91334 for ; Thu, 11 Apr 2002 00:11:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72F3D5DE5B; Thu, 11 Apr 2002 00:11:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0B9755DDD2 for ; Thu, 11 Apr 2002 00:11:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3B3RkW00869 for ; Wed, 10 Apr 2002 20:27:46 -0700 Date: Wed, 10 Apr 2002 20:27:46 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Last Call on draft-ietf-aaa-diameter-10.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on the Diameter Base specification, before sending this on to the IESG for consideration as a Proposed Standard. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-10.txt Please post issues with this document to aaa-wg@merit.edu by April 25, 2002, using the issue format described on the AAA issues list at: http://www.drizzle.com/~aboba/AAA/issues.html Note that the intent is for this to be the last AAA WG last call on this document, so if you have not read it carefully lately, now is the time. From owner-aaa-wg@merit.edu Thu Apr 11 04:51:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22439 for ; Thu, 11 Apr 2002 04:51:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 791C79122C; Thu, 11 Apr 2002 04:51:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 431BB912F9; Thu, 11 Apr 2002 04:51:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3FFC9122C for ; Thu, 11 Apr 2002 04:51:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD1775DDCC; Thu, 11 Apr 2002 04:51:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 14B4B5DD94 for ; Thu, 11 Apr 2002 04:51:11 -0400 (EDT) Received: from BOA (a7.local.ipunplugged.com [192.168.4.177]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g3B8sl4b003986 for ; Thu, 11 Apr 2002 10:54:47 +0200 Reply-To: From: "Bo Landarv" To: Subject: [AAA-WG]: [issue] Only DWR/DWA to be used to supervise transport connection Date: Thu, 11 Apr 2002 10:50:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Bo Landarv Submitter email address: bo.landarv@ipunplugged.com Date first submitted: April 11, 2002 Reference: Document: transport-06 Comment type: T Priority: 1 Section: Appendix A Rationale/Explanation of issue: Appendix A gives the impression that any request can be used to supervise the connection. If we have an outstanding session-related request it can take the role of the DWR. The DWR/DWA sending and receiving is a simple mechanism between two neighbours. An arbitrary request/answer pair, on the other hand, might involve proxies, complicated processing etc and should not IMHO be able to in any way affect the status of the connection. Requested change: State that "Pending" is set to true if and only if there is an outstanding, unanswered DWR. Procedure OnSendRequest should not call action SetWatchdog(). From owner-aaa-wg@merit.edu Thu Apr 11 06:54:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23870 for ; Thu, 11 Apr 2002 06:54:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5DF0912F9; Thu, 11 Apr 2002 06:53:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81586912FB; Thu, 11 Apr 2002 06:53:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EE7E912F9 for ; Thu, 11 Apr 2002 06:53:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E06B5DD9D; Thu, 11 Apr 2002 06:53:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id ABC695DD99 for ; Thu, 11 Apr 2002 06:53:52 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BArps7023696 for ; Thu, 11 Apr 2002 12:53:51 +0200 (MEST) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 12:52:27 2002 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 12:52:27 +0200 Message-ID: <577066326047D41180AC00508B955DDA06C4520C@eestqnt104> From: "Carolina Canales Valenzuela (ECE)" To: aaa-wg Cc: "Harri Hakala (LMF)" , "Victor Manuel Avila Gonzalez (ECE)" , "Tony Johansson (EUS)" , "Kevin Purser (EUS)" Subject: [AAA-WG]: [issue] User-Name AVP optional in ACR (base#10) Date: Thu, 11 Apr 2002 12:52:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23870 Issue: User-Name AVP optional in ACR, ACA Submitter name: Carolina Canales Submitter email address: carolina.canales-valenzuela@ece.ericsson.se Date first submitted: 04-11-2002 Reference: Document: diameter-base-10 Comment type: Technical Priority: S Section: 9.7.1, 9.7.2, 10.2 Rationale: It seems there is a contradiction between the use of the User-Name AVP stated in ABNF definition of the ACR, ACA commands (sect 9.7.1, 9.7.2), and what is stated in the AVP table (sect. 10.2). In the ABNF of the ACR the User-Name AVP is optional: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } ...... [ User-Name ] however in the AVP table in sect. 10.2 it is stated as mandatory for ACR (1) +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 1 | 0-1 | Requested Change: Change the AVP table in sect 10.2 to reflect that User-Name is optional in ACR (it was agreed by the WG in previous emails that sometimes the accounting client might not know the user name, or at least with a NAI format as it is required by the User-Name definition). | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 0-1 | 0-1 | Carolina Canales-Valenzuela Systems Engineer UMTS/GSM Systems Management R&D Center Ericsson España, S.A. Ombú, 3 Phone: +34 91 339 2680 28045 Madrid Fax: +34 91 339 2538 SPAIN e-mail: carolina.canales-valenzuela@ece.ericsson.se >-----Original Message----- >From: Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] >Sent: Tuesday, March 26, 2002 8:16 PM >To: John Loughney >Cc: aaa-wg >Subject: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 > > >Hi John, > >Issue : Minor corrections/clarifications to base-10 >Submitter name: Bob Kopacz >Submitter email address:bkopacz@interlinknetworks.com >Date first submitted: 03-26-2002 >Reference: >Document: draft-base-10 >Comment type: Technical >Priority: 1 >Section: > >Rationale/Explanation of issue: > > Minor corrections/clarifications to base-10. > >Requested change: > > >In section 1.1.1 Differences from Radius > >Change "Radius" to all caps in the section title. > >- - - > >In section 6.1.8 Relaying and Proxying Requests > >Change the first two lines of the following paragraph: > > Relay and Proxy agents MAY include the Proxy-Info AVP in requests if > it requires access any local state information when the corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > >To (four changes "A"... "or"... "agent"... "to"): > > A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if > it requires access to any local state information when the >corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > >- - - > >In section 7.1 Result-Code AVP > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages MUST include > one Result-Code AVP. A non-successful Result-Code AVP (one >containing > a non 2xxx value) MUST include the Error-Reporting-Host AVP if the > host setting the Result-Code AVP is different from the identity > encoded in the Origin-Host AVP. > >Change the parenthesized phrase in the preceding paragraph: > > (one containing a non 2xxx value) > >To: > > (one containing a non 2xxx value other than >DIAMETER_REDIRECT_INDICATION) > >- - - > >In section 8 DIAMETER USER SESSIONS > > Services provided past the expiration of the Authorization- > Lifetime and Auth-Grace-Period AVPs is the responsibility of the > access device. > >Change "is the responsibility" to "are the responsibility". > >- - - > >In section 8.4 Session Termination > > It is also possible that a session that was authorized is never > actually started due to action of a proxy. For example, a proxy may > modify an authorization answer, converting the result from success to > failure, prior to forwarding the message to the access device. A > proxy that causes an authorized session not to be started MUST issue > an STR to the Diameter server that authorized the session, since the > access device has no way of knowing that the session had been > authorized. > >Change the last sentence of the preceding paragraph to: > > If the answer did not contain an Auth-Session-State AVP with >the value > NO_STATE_MAINTAINED, a proxy that causes an authorized >session not to be > started MUST issue an STR to the Diameter server that authorized the > session, since the access device has no way of knowing that >the session > had been authorized. > >- - - > >In section 8.12 Re-Auth-Request-Type AVP > >Following this sentence: > > The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and > is included in application-specific auth answers to inform the client > of the action expected upon expiration of the Authorization-Lifetime. > >Add the following sentence: > > If the answer message contains an Authorization-Lifetime AVP with a > positive value, the Re-Auth-Request-Type AVP MUST be present >in an answer > message. > >- - - > >In section 8.13 Session-Timeout AVP > >Change the following sentence: > > A Session-Timeout AVP MAY be present in a re-authorization message, > and contains the number of seconds from the beginning of the re-auth. > >To: > > A Session-Timeout AVP MAY be present in a re-authorization >answer message, > and contains the remaining number of seconds from the >beginning of the > re-auth. > >- - - > >In section 8.17 Session-Binding AVP > >Change: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP MUST be present in all > accounting messages for this session. > >To: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP, if known, MUST be present in all > accounting messages for this session. > >The reason for adding the "if known" phrase is this: The >accounting server >may be different from the authentication server, and if so, >probably isn't >known when the first accounting message is sent. For subsequent >accounting messages, the accounting server is known by the >client and the >Destination-Host can be included from then on. > >- - - > >Throughout the document: > >Change "Accounting-Multi-Session-Id" to "Acct-Multi-Session-Id". Since >this is an AVP inherited from RADIUS, it should retain the RADIUS name. > >- - - > >In section 10.1 Base Protocol Command AVP Table > >Change: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0 |... > >To: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0+ |... > >- - - > >In section 10.2 Accounting AVP Table > >Change the sentence: > > The table in this section is used to represent which AVPs defined in > this document are to be present in the Accounting messages. > >To: > > The table in this section is used to represent which AVPs >defined in this > document are to be present in the Accounting messages. These AVP > occurrence requirements are guidelines which may be expanded and/or > overriden by application-specific requirements in the Diameter > applications documents. > >- - - > >In section 10.2 Accounting AVP Table > >Add these entries: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > Auth-Application-Id | 0 | 0 | > Termination-Cause | 0-1 | 0-1 | > Event-Timestamp | 0-1 | 0-1 | > >- - - > >In section 10.2 Accounting AVP Table > >Change: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 0+ | 0+ | > >To: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 1 | 0-1 | > >The thinking is, that since the Session-Id AVP requirement is "1", this >means the accounting message is for a specific session and hence for a >specific user, so the User-Name requirement is also "1". And the >User-Name is optionally echoed back in the ACA (per >issue#264), hence the >"0-1". > >- - - > From owner-aaa-wg@merit.edu Thu Apr 11 07:20:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24152 for ; Thu, 11 Apr 2002 07:20:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD5D6912FB; Thu, 11 Apr 2002 07:19:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBABC91335; Thu, 11 Apr 2002 07:19:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDB76912FB for ; Thu, 11 Apr 2002 07:19:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C25DA5DDB9; Thu, 11 Apr 2002 07:19:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 4AAD85DDA1 for ; Thu, 11 Apr 2002 07:19:50 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BBJk3G013053 for ; Thu, 11 Apr 2002 13:19:46 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 13:16:11 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTHKQ3>; Thu, 11 Apr 2002 13:16:12 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA0301F947CC@efijont102> From: "Harri Hakala (LMF)" To: "'aaa-wg'" Cc: "Victor Manuel Avila Gonzalez (ECE)" , "Tony Johansson (EUS)" , "Kevin Purser (EUS)" , "Carolina Canales Valenzuela (ECE)" Subject: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Date: Thu, 11 Apr 2002 13:15:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA24152 Hi, I think that same applies to the ASR and STR commands. See 8.4.1, 8.5.1 and 10.1. Regards.......Harri -----Original Message----- From: Carolina Canales Valenzuela (ECE) Sent: 11. huhtikuuta 2002 13:52 To: aaa-wg Cc: Harri Hakala (LMF); Victor Manuel Avila Gonzalez (ECE); Tony Johansson (EUS); Kevin Purser (EUS) Subject: [issue] User-Name AVP optional in ACR (base#10) Issue: User-Name AVP optional in ACR, ACA Submitter name: Carolina Canales Submitter email address: carolina.canales-valenzuela@ece.ericsson.se Date first submitted: 04-11-2002 Reference: Document: diameter-base-10 Comment type: Technical Priority: S Section: 9.7.1, 9.7.2, 10.2 Rationale: It seems there is a contradiction between the use of the User-Name AVP stated in ABNF definition of the ACR, ACA commands (sect 9.7.1, 9.7.2), and what is stated in the AVP table (sect. 10.2). In the ABNF of the ACR the User-Name AVP is optional: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } ...... [ User-Name ] however in the AVP table in sect. 10.2 it is stated as mandatory for ACR (1) +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 1 | 0-1 | Requested Change: Change the AVP table in sect 10.2 to reflect that User-Name is optional in ACR (it was agreed by the WG in previous emails that sometimes the accounting client might not know the user name, or at least with a NAI format as it is required by the User-Name definition). | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ------------------------------|-----+-----+ User-Name | 0-1 | 0-1 | Carolina Canales-Valenzuela Systems Engineer UMTS/GSM Systems Management R&D Center Ericsson España, S.A. Ombú, 3 Phone: +34 91 339 2680 28045 Madrid Fax: +34 91 339 2538 SPAIN e-mail: carolina.canales-valenzuela@ece.ericsson.se >-----Original Message----- >From: Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] >Sent: Tuesday, March 26, 2002 8:16 PM >To: John Loughney >Cc: aaa-wg >Subject: [AAA-WG]: [issue] Minor corrections/clarifications to base-10 > > >Hi John, > >Issue : Minor corrections/clarifications to base-10 >Submitter name: Bob Kopacz >Submitter email address:bkopacz@interlinknetworks.com >Date first submitted: 03-26-2002 >Reference: >Document: draft-base-10 >Comment type: Technical >Priority: 1 >Section: > >Rationale/Explanation of issue: > > Minor corrections/clarifications to base-10. > >Requested change: > > >In section 1.1.1 Differences from Radius > >Change "Radius" to all caps in the section title. > >- - - > >In section 6.1.8 Relaying and Proxying Requests > >Change the first two lines of the following paragraph: > > Relay and Proxy agents MAY include the Proxy-Info AVP in requests if > it requires access any local state information when the corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > >To (four changes "A"... "or"... "agent"... "to"): > > A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if > it requires access to any local state information when the >corresponding > response is received. Alternatively, it MAY simply use local storage > to store state information. > >- - - > >In section 7.1 Result-Code AVP > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages MUST include > one Result-Code AVP. A non-successful Result-Code AVP (one >containing > a non 2xxx value) MUST include the Error-Reporting-Host AVP if the > host setting the Result-Code AVP is different from the identity > encoded in the Origin-Host AVP. > >Change the parenthesized phrase in the preceding paragraph: > > (one containing a non 2xxx value) > >To: > > (one containing a non 2xxx value other than >DIAMETER_REDIRECT_INDICATION) > >- - - > >In section 8 DIAMETER USER SESSIONS > > Services provided past the expiration of the Authorization- > Lifetime and Auth-Grace-Period AVPs is the responsibility of the > access device. > >Change "is the responsibility" to "are the responsibility". > >- - - > >In section 8.4 Session Termination > > It is also possible that a session that was authorized is never > actually started due to action of a proxy. For example, a proxy may > modify an authorization answer, converting the result from success to > failure, prior to forwarding the message to the access device. A > proxy that causes an authorized session not to be started MUST issue > an STR to the Diameter server that authorized the session, since the > access device has no way of knowing that the session had been > authorized. > >Change the last sentence of the preceding paragraph to: > > If the answer did not contain an Auth-Session-State AVP with >the value > NO_STATE_MAINTAINED, a proxy that causes an authorized >session not to be > started MUST issue an STR to the Diameter server that authorized the > session, since the access device has no way of knowing that >the session > had been authorized. > >- - - > >In section 8.12 Re-Auth-Request-Type AVP > >Following this sentence: > > The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and > is included in application-specific auth answers to inform the client > of the action expected upon expiration of the Authorization-Lifetime. > >Add the following sentence: > > If the answer message contains an Authorization-Lifetime AVP with a > positive value, the Re-Auth-Request-Type AVP MUST be present >in an answer > message. > >- - - > >In section 8.13 Session-Timeout AVP > >Change the following sentence: > > A Session-Timeout AVP MAY be present in a re-authorization message, > and contains the number of seconds from the beginning of the re-auth. > >To: > > A Session-Timeout AVP MAY be present in a re-authorization >answer message, > and contains the remaining number of seconds from the >beginning of the > re-auth. > >- - - > >In section 8.17 Session-Binding AVP > >Change: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP MUST be present in all > accounting messages for this session. > >To: > > ACCOUNTING 4 > When set, all accounting messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP, if known, MUST be present in all > accounting messages for this session. > >The reason for adding the "if known" phrase is this: The >accounting server >may be different from the authentication server, and if so, >probably isn't >known when the first accounting message is sent. For subsequent >accounting messages, the accounting server is known by the >client and the >Destination-Host can be included from then on. > >- - - > >Throughout the document: > >Change "Accounting-Multi-Session-Id" to "Acct-Multi-Session-Id". Since >this is an AVP inherited from RADIUS, it should retain the RADIUS name. > >- - - > >In section 10.1 Base Protocol Command AVP Table > >Change: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0 |... > >To: > > Attribute Name |CER|CEA|... > --------------------|---+---+... > Supported-Vendor-Id |0+ |0+ |... > >- - - > >In section 10.2 Accounting AVP Table > >Change the sentence: > > The table in this section is used to represent which AVPs defined in > this document are to be present in the Accounting messages. > >To: > > The table in this section is used to represent which AVPs >defined in this > document are to be present in the Accounting messages. These AVP > occurrence requirements are guidelines which may be expanded and/or > overriden by application-specific requirements in the Diameter > applications documents. > >- - - > >In section 10.2 Accounting AVP Table > >Add these entries: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > Auth-Application-Id | 0 | 0 | > Termination-Cause | 0-1 | 0-1 | > Event-Timestamp | 0-1 | 0-1 | > >- - - > >In section 10.2 Accounting AVP Table > >Change: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 0+ | 0+ | > >To: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 1 | 0-1 | > >The thinking is, that since the Session-Id AVP requirement is "1", this >means the accounting message is for a specific session and hence for a >specific user, so the User-Name requirement is also "1". And the >User-Name is optionally echoed back in the ACA (per >issue#264), hence the >"0-1". > >- - - > From owner-aaa-wg@merit.edu Thu Apr 11 08:43:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25708 for ; Thu, 11 Apr 2002 08:43:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D0DD91337; Thu, 11 Apr 2002 08:42:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E276591338; Thu, 11 Apr 2002 08:42:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B836991337 for ; Thu, 11 Apr 2002 08:42:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9418B5DE60; Thu, 11 Apr 2002 08:42:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 5838A5DD99 for ; Thu, 11 Apr 2002 08:42:46 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BEA266A901; Thu, 11 Apr 2002 15:42:00 +0300 (EEST) Message-ID: <3CB576F2.2070503@kolumbus.fi> Date: Thu, 11 Apr 2002 14:43:46 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Carolina Canales Valenzuela (ECE)" Cc: aaa-wg , "Harri Hakala (LMF)" , "Victor Manuel Avila Gonzalez (ECE)" , "Tony Johansson (EUS)" , "Kevin Purser (EUS)" Subject: Re: [AAA-WG]: [issue] User-Name AVP optional in ACR (base#10) References: <577066326047D41180AC00508B955DDA06C4520C@eestqnt104> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Carolina Canales Valenzuela (ECE) wrote: > Issue: User-Name AVP optional in ACR, ACA > Submitter name: Carolina Canales > Submitter email address: carolina.canales-valenzuela@ece.ericsson.se > Date first submitted: 04-11-2002 > Reference: > Document: diameter-base-10 > Comment type: Technical > Priority: S > Section: 9.7.1, 9.7.2, 10.2 > > Rationale: > > It seems there is a contradiction between the use of the User-Name AVP stated in ABNF definition of the ACR, ACA commands (sect 9.7.1, 9.7.2), and what is stated in the AVP table (sect. 10.2). Agree. This appears to a missed modification on the earlier issue which observed that User-Name AVP isn't always available. Harri wrote: > I think that same applies to the ASR and STR commands. > See 8.4.1, 8.5.1 and 10.1. Yes, this too. Jari From owner-aaa-wg@merit.edu Thu Apr 11 08:53:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26021 for ; Thu, 11 Apr 2002 08:53:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 698D791338; Thu, 11 Apr 2002 08:52:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34F0391339; Thu, 11 Apr 2002 08:52:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2313491338 for ; Thu, 11 Apr 2002 08:52:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0056F5DE67; Thu, 11 Apr 2002 08:52:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 5AF355DE2F for ; Thu, 11 Apr 2002 08:52:51 -0400 (EDT) Received: (qmail 342 invoked by uid 500); 11 Apr 2002 12:52:50 -0000 Date: Thu, 11 Apr 2002 07:52:50 -0500 From: David Frascone To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020411125250.GA28851@newman.frascone.com> Mail-Followup-To: Bernard Aboba , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree with this fully. Peers can advertise whether or not they support TLS in the CEA/CER. If both peers support TLS, then after the Diameter handshake, a TLS handshake can start. The only gotcha is when the TLS handshake fails. Do the peers just fall back to non-secure operation? -Dave On Wednesday, 10 Apr 2002, Bernard Aboba wrote: > Issue 330: Diameter should not require separate TLS port > Submitter name: Allison Mankin > Submitter email address: mankin@isi.edu > Date first submitted: 04-10-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: S > Section: 2.1 (contradicts section 13.3) > > Justification: The IESG is encouraging WGs to enable their > applications to negotiate an upgrade to TLS rather than requiring > a separate port. Diameter cannot yet handle this "startTLS" > up-negotiation. Do not assume that Diameter will be granted > an addition port for use with TLS. > > Change: > Need support for TLS up-negotiation in Diameter. > > -- David Frascone Copy from another: plagiarism. Copy from many: research. From owner-aaa-wg@merit.edu Thu Apr 11 08:54:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26071 for ; Thu, 11 Apr 2002 08:54:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E61F91339; Thu, 11 Apr 2002 08:54:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1E979133A; Thu, 11 Apr 2002 08:54:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D016D91339 for ; Thu, 11 Apr 2002 08:54:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACDEB5DE67; Thu, 11 Apr 2002 08:54:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 066275DE2F for ; Thu, 11 Apr 2002 08:54:14 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BCsE3G014761 for ; Thu, 11 Apr 2002 14:54:14 +0200 (MEST) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 14:54:11 2002 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 14:54:11 +0200 Message-ID: <577066326047D41180AC00508B955DDA06C4520D@eestqnt104> From: "Carolina Canales Valenzuela (ECE)" To: "Tony Johansson (EUS)" , "Kevin Purser (EUS)" Cc: aaa-wg@merit.edu, Pete McCann , jaakko.rajaniemi@nokia.com, Johanna.Wild@motorola.com, nhberry@lucent.com, dlwarren@nortelnetworks.com, peter.schmitt@icn.siemens.de, mikko.aittola@nokia.com, "Miguel-Angel Pallares-Lopez (ECE)" Subject: [AAA-WG]: Diameter Multimedia Application - New AVP Date: Thu, 11 Apr 2002 14:53:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA26071 Hello, although I know that the WG will not discuss any issue that is not related with the main drafts until these are ready, I have some comments for the editor of the Diameter Multimedia Application (http://search.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt ), and I think it is interesting to share them with the whole WG. I'd like to add a new AVP to the grouped AVP SIP-Auth-Data-Item. The name of this new AVP would be "SIP-Authentication-Info AVP" and would contain additional authentication information that can be sent from the AAA server to the user terminal as stated in RFC2617 "HTTP Authentication: Basic and Digest Access Authentication" (e.g., next nonce) when Digest authentication is used . The content of this AVP would be mapped to the SIP Authentication-Info header upon its reception by the SIP server. This would be the new definition of the SIP-Auth-Data-Item AVP (sect 6.13)considering this: SIP-Auth-Data-Item :: = < AVP Header : TBD > [ SIP-Item-Number ] [ SIP-Authentication-Scheme ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Info ] [ SIP-Authentication-Context ] * [ NAS-Session-Key ] * [ AVP ] and this would be the definition of the AVP, to be added to text: x.x SIP-Authentication-Info AVP The SIP-Authentication-Info AVP (AVP Code TBD)is of type OctetString and contains additional authentication information sent by the AAA server in case of Digest authentication. It follows the format defined in RFC2617 for the Authentication-Info Header (sect 3.2.3). The content of this AVP would be mapped to the SIP Authentication-Info header upon its reception by the SIP server. Any comments/objections? BR, Carolina Carolina Canales-Valenzuela Systems Engineer UMTS/GSM Systems Management R&D Center Ericsson España, S.A. Ombú, 3 Phone: +34 91 339 2680 28045 Madrid Fax: +34 91 339 2538 SPAIN e-mail: carolina.canales-valenzuela@ece.ericsson.se From owner-aaa-wg@merit.edu Thu Apr 11 10:33:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28248 for ; Thu, 11 Apr 2002 10:33:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 094059122F; Thu, 11 Apr 2002 10:33:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C96BF91231; Thu, 11 Apr 2002 10:33:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F00EE9122F for ; Thu, 11 Apr 2002 10:32:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B09075DE86; Thu, 11 Apr 2002 10:32:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9B81E5DE18 for ; Thu, 11 Apr 2002 10:32:01 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id C8C9B6C; Thu, 11 Apr 2002 10:31:59 -0400 (EDT) From: "Bob Kopacz" To: "Carolina Canales Valenzuela (ECE)" Cc: "aaa-wg" Subject: RE: [AAA-WG]: [issue] User-Name AVP optional in ACR (base#10) Date: Thu, 11 Apr 2002 10:30:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <577066326047D41180AC00508B955DDA06C4520C@eestqnt104> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Carolina, > Requested Change: > > Change the AVP table in sect 10.2 to reflect that User-Name is > optional in ACR (it was agreed by the WG in previous emails that > sometimes the accounting client might not know the user name, or at > least with a NAI format as it is required by the User-Name definition). In my ignorance of the above, I had submitted an issue, part of which asked to change the User-Name AVP occurrence rule for an ACR from "0+" to "1". Sorry for the confusion I caused. Bob K. From owner-aaa-wg@merit.edu Thu Apr 11 10:38:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28363 for ; Thu, 11 Apr 2002 10:38:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1DC6791231; Thu, 11 Apr 2002 10:38:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6164912C2; Thu, 11 Apr 2002 10:38:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7D4791231 for ; Thu, 11 Apr 2002 10:38:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1E945DEA2; Thu, 11 Apr 2002 10:38:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 43E0A5DE9E for ; Thu, 11 Apr 2002 10:38:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3BDsKf31026; Thu, 11 Apr 2002 06:54:20 -0700 Date: Thu, 11 Apr 2002 06:54:20 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Only DWR/DWA to be used to supervise transport connection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #334. On Thu, 11 Apr 2002, Bo Landarv wrote: > > Submitter name: Bo Landarv > Submitter email address: bo.landarv@ipunplugged.com > Date first submitted: April 11, 2002 > Reference: > Document: transport-06 > Comment type: T > Priority: 1 > Section: Appendix A > Rationale/Explanation of issue: > > Appendix A gives the impression that any request can be used to > supervise the connection. If we have an outstanding session-related > request it can take the role of the DWR. > > The DWR/DWA sending and receiving is a simple mechanism between > two neighbours. An arbitrary request/answer pair, on the other hand, > might involve proxies, complicated processing etc and should not > IMHO be able to in any way affect the status of the connection. > > Requested change: > > State that "Pending" is set to true if and only if there is an > outstanding, unanswered DWR. > Procedure OnSendRequest should not call action SetWatchdog(). > From owner-aaa-wg@merit.edu Thu Apr 11 10:50:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28698 for ; Thu, 11 Apr 2002 10:50:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19A8591230; Thu, 11 Apr 2002 10:50:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBDAB912C2; Thu, 11 Apr 2002 10:50:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2C2691230 for ; Thu, 11 Apr 2002 10:50:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EFDE5DE9E; Thu, 11 Apr 2002 10:50:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id A6E525DEAE for ; Thu, 11 Apr 2002 10:50:16 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3BEo5b08073 for ; Thu, 11 Apr 2002 15:50:05 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 11 Apr 2002 15:44:41 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA23831; Thu, 11 Apr 2002 15:49:59 +0100 Message-ID: <3CB5A29D.11AFA9DE@baltimore.ie> Date: Thu, 11 Apr 2002 15:50:05 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port References: <20020411125250.GA28851@newman.frascone.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, > The only gotcha is when the TLS handshake fails. Do the peers just fall > back to non-secure operation? Eh - if so, why'd they bother trying to turn on TLS? Anyone with access to the network can tweak bits and cause the TLS handshake to fail, so the answer to your question has to be a resounding "no". Stephen. > > -Dave > > On Wednesday, 10 Apr 2002, Bernard Aboba wrote: > > Issue 330: Diameter should not require separate TLS port > > Submitter name: Allison Mankin > > Submitter email address: mankin@isi.edu > > Date first submitted: 04-10-2002 > > Reference: > > Document: draft-base-10 > > Comment type: Technical > > Priority: S > > Section: 2.1 (contradicts section 13.3) > > > > Justification: The IESG is encouraging WGs to enable their > > applications to negotiate an upgrade to TLS rather than requiring > > a separate port. Diameter cannot yet handle this "startTLS" > > up-negotiation. Do not assume that Diameter will be granted > > an addition port for use with TLS. > > > > Change: > > Need support for TLS up-negotiation in Diameter. > > > > > > -- > David Frascone > > Copy from another: plagiarism. Copy from many: research. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Apr 11 11:03:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29293 for ; Thu, 11 Apr 2002 11:03:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 08F1191335; Thu, 11 Apr 2002 11:03:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A62BE912C2; Thu, 11 Apr 2002 11:03:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C4919133A for ; Thu, 11 Apr 2002 11:02:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67F425DE7D; Thu, 11 Apr 2002 11:02:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 6963E5DD96 for ; Thu, 11 Apr 2002 11:02:47 -0400 (EDT) Received: (qmail 1927 invoked by uid 500); 11 Apr 2002 15:02:36 -0000 Date: Thu, 11 Apr 2002 10:02:35 -0500 From: David Frascone To: Stephen Farrell Cc: David Frascone , Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020411150235.GC28851@newman.frascone.com> Mail-Followup-To: Stephen Farrell , David Frascone , Bernard Aboba , aaa-wg@merit.edu References: <20020411125250.GA28851@newman.frascone.com> <3CB5A29D.11AFA9DE@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB5A29D.11AFA9DE@baltimore.ie> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Good point. On Thursday, 11 Apr 2002, Stephen Farrell wrote: > > Dave, > > > The only gotcha is when the TLS handshake fails. Do the peers just fall > > back to non-secure operation? > > Eh - if so, why'd they bother trying to turn on TLS? Anyone with access > to the network can tweak bits and cause the TLS handshake to fail, so > the answer to your question has to be a resounding "no". > > Stephen. > -- David Frascone I can't hear you. There's a banana republic in my ear. From owner-aaa-wg@merit.edu Thu Apr 11 11:36:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00140 for ; Thu, 11 Apr 2002 11:36:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9C56912C2; Thu, 11 Apr 2002 11:36:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD68A91336; Thu, 11 Apr 2002 11:36:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AFAE4912C2 for ; Thu, 11 Apr 2002 11:36:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CF5E5DEBD; Thu, 11 Apr 2002 11:36:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 779E35DE6F for ; Thu, 11 Apr 2002 11:36:10 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 423266C; Thu, 11 Apr 2002 11:36:10 -0400 (EDT) From: "Bob Kopacz" To: "Tony Johansson" Cc: Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Thu, 11 Apr 2002 11:34:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CB4FA49.A95CE72D@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > > Does it make sense? > > [...] > > So if my above changes is ok, how about this: > Yes, what you say makes sense. The things that are still on my mind are: 1. Johan's comment (paraphrased as I understand it) that what is really needed for issue#301 is for the AAAH to know the identity of the destination AAAF hosting the foreign HA. Although by requiring a fixed AAAH over the life of a MN's session, the AAAH can (with some effort) come up with the AAAF's identity, why not instead have the MN cache the destination AAAF's identity instead of the AAAH's identity? This eliminates the seemingly unnecessary restriction, and single point of failure, of a fixed AAAH. On the other hand, a single AAAH does have some modest virtues: [a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't change, the HA doesn't have to clear the session with the old AAAH when a new AAAH comes on board; [c] does session/policy/resource management become easier with a fixed AAAH? 2. As a side issue to the problem of the AAAH wanting to set up an SA with the destination AAAF but not knowing the AAAF's identity, this may not be such a problem: I've just been told that a DSAR may be sent with a Destination-Realm but without a Destination-Host, when the Destination-Host isn't known. When the DSAA comes back, the node that sent the DSAR then learns the identity of the remote AAA server. 3. This is the first time there is text referring to the idea of a "pre-configured" SA between the foreign HA and the AAAH. I want to ask a couple questions about that, in a separate email. 4. The text makes references to CMS and DSAs. With CMS being held back, I don't know how Mobile IP security topics should be stated. Bob K. From owner-aaa-wg@merit.edu Thu Apr 11 11:49:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02520 for ; Thu, 11 Apr 2002 11:49:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19DF191336; Thu, 11 Apr 2002 11:48:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBF119133A; Thu, 11 Apr 2002 11:48:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5F5691336 for ; Thu, 11 Apr 2002 11:48:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BD0C5DEA1; Thu, 11 Apr 2002 11:48:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DF4515DEA0 for ; Thu, 11 Apr 2002 11:48:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3BF4vv02053; Thu, 11 Apr 2002 08:04:57 -0700 Date: Thu, 11 Apr 2002 08:04:57 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise transport connection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Let me see if I can summarize your issue and determine the source of the problem. That goal of the heartbeat is to allow peers to determine the "liveness" of their neighbors without adding unnecessary traffic. To quote from RFC 2865, section 2.6: " Some implementers have adopted the practice of sending test RADIUS requests to see if a server is alive. This practice is strongly discouraged, since it adds to load and harms scalability without providing any additional useful information." As a result, a heartbeat is only sent if there has been no other traffic to verify liveness of the peer. In a proxy or relay system, it is possible that the response will be delayed due to many factors, such as an overloaded or failed downstream proxy or server. It is important that issues encountered downstream not induce failover on a perfectly functional connection, since the immediate neighbor may have little to do with the cause of the delay. In the transport state machine described in Appendix A, normal traffic sent to a peer is included as part of the watchdog activity in order to avoid sending additional traffic unless absolutely necessary. The watchdog timer is reset whenever a response is received, including receipt of a watchdog response. On sending a message, if the send queue is empty, then the watchdog timer is reset. If the watchdog timer expires and the send queue is empty, then a watchdog packet is sent. If the watchdog timer expires and a response is pending, then failover is initiated. Let's look at a hypothetical case: A ------------- B ----------------- C B' --------------- C' Diameter client A is using relay B as the primary to talk to server C. However it also has relay B' as its secondary, which it can use to talk to server C or C'. Let's assume that B and B' are both healthy and that the connection between them and A are fine, but that there is a problem with C. Ideally, we'd want B to failover from C to C', and have this not affect the connection between A and B, since there is nothing wrong with this. If there was nothing in the send queue when A sent its request to B, then the watchdog timer would have been reset. Since there was a problem with C, B has to initiate its own failover to C', and as a result, a response may not be sent before A's watchdog timer expires. Since there is something in the send queue (A's request to B), failover will be initiated. This is wrong because had a watchdog been sent to B, then it would have received a reply and no failover would have occurred. Therefore, I think that the requested change is that failover only be initiated on failure to receive a response to a watchdog packet. While a successful response to any Diameter request can reset the watchdog timer, only a failure to receive a watchdog response can cause failover. One way to fix this might be to distinguish between what is in the send queue once the watchdog timer expires. Today, failover is initiated if the timer expires with something in the send queue, no matter what it is. However, when the watchdog timer is reset, the type of request ("Watchdog", or "Non-Watchdog") that is pending can be put into a state variable. This would enable failover only to be initiated when the timer expires with a "Watchdog" pending. If a "Non-Watchdog" is pending, then the watchdog timer can be reset and a watchdog packet can be sent. The issue with this is that it could require two watchdog intervals to detect a failure instead of one, in case there really is a failure in the dowstream relay or proxy. > Submitter name: Bo Landarv > Submitter email address: bo.landarv@ipunplugged.com > Date first submitted: April 11, 2002 > Reference: > Document: transport-06 > Comment type: T > Priority: 1 > Section: Appendix A > Rationale/Explanation of issue: > > Appendix A gives the impression that any request can be used to > supervise the connection. If we have an outstanding session-related > request it can take the role of the DWR. > > The DWR/DWA sending and receiving is a simple mechanism between > two neighbours. An arbitrary request/answer pair, on the other hand, > might involve proxies, complicated processing etc and should not > IMHO be able to in any way affect the status of the connection. > > Requested change: > > State that "Pending" is set to true if and only if there is an > outstanding, unanswered DWR. > Procedure OnSendRequest should not call action SetWatchdog(). > From owner-aaa-wg@merit.edu Thu Apr 11 12:33:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05156 for ; Thu, 11 Apr 2002 12:33:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 162919133D; Thu, 11 Apr 2002 12:33:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C75649133C; Thu, 11 Apr 2002 12:33:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2582A9133D for ; Thu, 11 Apr 2002 12:33:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 015725DEB1; Thu, 11 Apr 2002 12:33:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 476005DEA5 for ; Thu, 11 Apr 2002 12:33:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3BFnNv04171; Thu, 11 Apr 2002 08:49:23 -0700 Date: Thu, 11 Apr 2002 08:49:23 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise transport connection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The requested change is: State that "Pending" is set to true if and only if there is an outstanding, unanswered DWR. Procedure OnSendRequest should not call action SetWatchdog(). I think that this is correct. Let me describe what the overall algorithm now looks like: 1. The watchdog timer is reset whenever any response is received from the peer, including receipt of a watchdog response. 2. If the watchdog timer expires and there is no pending watchdog response, then the watchdog packet is sent and the watchdog timer is reset. 3. If the watchdog timer expires and there is a pending watchdog response, then failover is initiated. This simplifies things, since there is no need to deal with requests other than watchdogs. It appears to deal with the example: 1. If no packet had been sent in a while, then a watchdog packet would have been sent and the timer reset. As long as B kept answering the watchdog packets, the connection would stay up, regardless of whether B was failing over to C'. 2. As long as requests sent through B were being answered, the watchdog timer would be continuously reset and no watchdog packets would need to be sent. However, when C dies, the responses would stop and once the timer expired, then a watchdog would be sent from A to B. Since B would respond, the connection from A to B would stay up. From owner-aaa-wg@merit.edu Thu Apr 11 15:12:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10069 for ; Thu, 11 Apr 2002 15:12:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4225D91306; Thu, 11 Apr 2002 15:10:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E309F91307; Thu, 11 Apr 2002 15:10:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65EBE91306 for ; Thu, 11 Apr 2002 15:10:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 495985DD96; Thu, 11 Apr 2002 15:10:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D48BF5DE73 for ; Thu, 11 Apr 2002 15:10:07 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3BJA7i10095; Thu, 11 Apr 2002 14:10:07 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3BJA7M18506; Thu, 11 Apr 2002 14:10:07 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA29369; Thu, 11 Apr 2002 14:10:06 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA01204; Thu, 11 Apr 2002 14:10:05 -0500 (CDT) Message-ID: <3CB5DED8.9C37B76B@ericsson.com> Date: Thu, 11 Apr 2002 12:07:05 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, Bob Kopacz wrote: > > The things that are still on my mind are: > > 1. Johan's comment (paraphrased as I understand it) that what is really > needed for issue#301 is for the AAAH to know the identity of the > destination AAAF hosting the foreign HA. Although by requiring a fixed > AAAH over the life of a MN's session, the AAAH can (with some effort) come > up with the AAAF's identity, why not instead have the MN cache the > destination AAAF's identity instead of the AAAH's identity? This > eliminates the seemingly unnecessary restriction, and single point of > failure, of a fixed AAAH. > > > On the other hand, a single AAAH does have some modest virtues: > [a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new > SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't > change, the HA doesn't have to clear the session with the old AAAH when > a new AAAH comes on board; [c] does session/policy/resource management > become easier with a fixed AAAH? I definitely agree with what you state above and yes a believe that session/policy/resource management become easier with a fixed AAAH (especially since multiple AAAH's in the same domain may not be synchronized). > > > 2. As a side issue to the problem of the AAAH wanting to set up an SA > with the destination AAAF but not knowing the AAAF's identity, this may > not be such a problem: I've just been told that a DSAR may be sent with > a Destination-Realm but without a Destination-Host, when the > Destination-Host isn't known. When the DSAA comes back, the node that > sent the DSAR then learns the identity of the remote AAA server. > > 3. This is the first time there is text referring to the idea of a > "pre-configured" SA between the foreign HA and the AAAH. I want to ask > a couple questions about that, in a separate email. Please forget the "pre-configured" stuff . I wasn't thinking when I sent out the text yesterday :( Thank for the sanity check. So how about the following text instead in section 1.4: "If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key must be encrypted, the AAAH sends the HAR to the originating AAAF. In this HAR the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into the HAR. If no security association exists between the AAAH and the originating AAAF, the AAAH SHOULD make use of the CMS Strong Security Application [CMS] to establish this association. If the AAAH's local policy determines that no keys need to be encrypted, the HAR is sent by the AAAH back to the foreign realm with the Destination-Host AVP set to the home agent's identity. This HAR may not necessarily be received by the same AAAF, which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, this new AAAF will use the MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not. and in section 5.3: "If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent. If the session key needs to be encrypted the AAAH SHOULD encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP in a CMS-Encrypted-Data AVP using the security association with the AAAF associated with the home agent. If no security association exists between the AAAH and the AAAF associated with the home agent, the AAAH SHOULD check if a security association can be established, using the CMS application [CMS]. On the other hand, if no security association exists and cannot be created, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE." > > > 4. The text makes references to CMS and DSAs. With CMS being held back, > I don't know how Mobile IP security topics should be stated. I hope text like the above with [CMS] referenced as informative will be good enough. One of the conlusions from that meeting IESG security meeting yesterday was that they will look at the possibilities to get one of the security experts to help us to provide additional advice regarding this issue. > > > Bob K. From owner-aaa-wg@merit.edu Thu Apr 11 16:26:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12851 for ; Thu, 11 Apr 2002 16:26:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B29F91307; Thu, 11 Apr 2002 16:26:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 567C99133C; Thu, 11 Apr 2002 16:26:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4ED4B91307 for ; Thu, 11 Apr 2002 16:26:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29A615DDF6; Thu, 11 Apr 2002 16:26:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 10C855DD99 for ; Thu, 11 Apr 2002 16:26:38 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id D7F2C6C; Thu, 11 Apr 2002 16:26:37 -0400 (EDT) From: "Bob Kopacz" To: "Tony Johansson" Cc: Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Thu, 11 Apr 2002 16:25:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CB5DED8.9C37B76B@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Looks better all the time. I don't think I have any more to add right now, maybe something will come to me. Your modified text looks fine. Bob K. > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Thursday, April 11, 2002 3:07 PM > To: Bob Kopacz > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > > Hi Bob, > > Bob Kopacz wrote: > > > > The things that are still on my mind are: > > > > 1. Johan's comment (paraphrased as I understand it) that what is really > > needed for issue#301 is for the AAAH to know the identity of the > > destination AAAF hosting the foreign HA. Although by requiring a fixed > > AAAH over the life of a MN's session, the AAAH can (with some effort) come > > up with the AAAF's identity, why not instead have the MN cache the > > destination AAAF's identity instead of the AAAH's identity? This > > eliminates the seemingly unnecessary restriction, and single point of > > failure, of a fixed AAAH. > > > > On the other hand, a single AAAH does have some modest virtues: > > [a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new > > SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't > > change, the HA doesn't have to clear the session with the old AAAH when > > a new AAAH comes on board; [c] does session/policy/resource management > > become easier with a fixed AAAH? > > I definitely agree with what you state above and yes a believe that > session/policy/resource management > become easier with a fixed AAAH (especially since multiple AAAH's in the same > domain may not be synchronized). > > > > > > > 2. As a side issue to the problem of the AAAH wanting to set up an SA > > with the destination AAAF but not knowing the AAAF's identity, this may > > not be such a problem: I've just been told that a DSAR may be sent with > > a Destination-Realm but without a Destination-Host, when the > > Destination-Host isn't known. When the DSAA comes back, the node that > > sent the DSAR then learns the identity of the remote AAA server. > > > > 3. This is the first time there is text referring to the idea of a > > "pre-configured" SA between the foreign HA and the AAAH. I want to ask > > a couple questions about that, in a separate email. > > Please forget the "pre-configured" stuff . I wasn't thinking when I sent out > the text yesterday :( Thank for the sanity check. > > So how about the following text instead in section 1.4: > > "If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key > must be encrypted, the AAAH sends the HAR to the originating AAAF. In this HAR > the Destination-Host AVP is set to the value found in the AMR's > MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the > MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into the HAR. > If no security association exists between the AAAH and the originating AAAF, > the AAAH SHOULD make use of the CMS Strong Security Application [CMS] to > establish this association. > > If the AAAH's local policy determines that no keys need to be encrypted, the > HAR is sent by the AAAH back to the foreign realm with the Destination-Host > AVP set to the home agent's identity. This HAR may not necessarily be received > by the same AAAF, which sent the AMR. Therefore the AAAH MUST always copy the > MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In > cases when another AAAF receives the HAR, this new AAAF will use the > MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if > the FA-HA Key should be encrypted or not. > > and in section 5.3: > > "If, on the other hand, the home agent is to be allocated in the visited > realm, the AAAH transmits the HAR to the foreign home agent, where, prior to > delivery to the home agent, it is perused by the AAAF hosting the home agent. > If the session key needs to be encrypted the AAAH SHOULD encrypt the > MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP in a CMS-Encrypted-Data AVP > using the security association with the AAAF associated with the home agent. > If no security association exists between the AAAH and the AAAF associated > with the home agent, the AAAH SHOULD check if a security association can be > established, using the CMS application [CMS]. On the other hand, if no > security association exists and cannot be created, the AAAH MUST return a > Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE." > > > > > > > 4. The text makes references to CMS and DSAs. With CMS being held back, > > I don't know how Mobile IP security topics should be stated. > > I hope text like the above with [CMS] referenced as informative will be good > enough. One of the conlusions from that meeting IESG security meeting > yesterday was that they will look at the possibilities to get one of the > security experts to help us to provide additional advice regarding this issue. > > > > > > > Bob K. > > From owner-aaa-wg@merit.edu Thu Apr 11 19:42:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20174 for ; Thu, 11 Apr 2002 19:42:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68C2D9123B; Thu, 11 Apr 2002 19:41:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EED89124E; Thu, 11 Apr 2002 19:41:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C19DC9123B for ; Thu, 11 Apr 2002 19:41:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FF955DE60; Thu, 11 Apr 2002 19:41:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2B4B55DE4E for ; Thu, 11 Apr 2002 19:41:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3BMvXA25012; Thu, 11 Apr 2002 15:57:33 -0700 Date: Thu, 11 Apr 2002 15:57:33 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu, randy@psg.com, mankin@isi.edu, jonwood@speakeasy.net Subject: Re: [AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise transport connection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've proposed new text in a "transport-07" strawman document to address issue #334. The new version is available for inspection at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-07.txt Please let me know ASAP if the proposed text is satisfactory. Substantial changes were required in section 3.4 as well as in Appendix A to provide the fix, so that a careful read of the new text would be appreciated. From owner-aaa-wg@merit.edu Thu Apr 11 22:40:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05523 for ; Thu, 11 Apr 2002 22:40:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 184CF91243; Thu, 11 Apr 2002 22:40:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE64A91244; Thu, 11 Apr 2002 22:40:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC41491243 for ; Thu, 11 Apr 2002 22:40:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC08A5DE69; Thu, 11 Apr 2002 22:40:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2EB095DDA3 for ; Thu, 11 Apr 2002 22:40:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3C1ukC01165; Thu, 11 Apr 2002 18:56:46 -0700 Date: Thu, 11 Apr 2002 18:56:46 -0700 (PDT) From: Bernard Aboba To: Jonathan Wood Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Diameter Issue #334 In-Reply-To: <7DD39D5B-4DB9-11D6-97CC-0003930D291E@speakeasy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > One side effect we should consider is what will happen to the simple > case, > where there are no proxies involved. I think the proposed change might > increase the time til failover by up to T (the watchdog timeout) in some > cases. > > For example: > > A ----------------- B > B' > > Diameter client A is talking with server B. If B fails while A is > exchanging messages with it, A will have to wait for the next watchdog > timer to fire to probe the connection, and then wait for another > watchdog timeout before it fails over to B'. I think you are correct. In the proposed solution to #334, the timer is reset on receipt of a response. So if B dies after the last response, then A's timer will fire Tw after that, send a watchdog and then fail over after another Tw. Whereas under the -06 algorithm, the next request would have simultaneously reset the timer and set the "pending" flag, so that failover would occur after Tw. I think the performance of both algorithms is roughly the same for a very unloaded network, since that would mean that watchdog responses would cause resetting of the timers and failover should occur within a single Tw. > Of course, if the watchdog timeout is long enough or the client is > sending lots of traffic, the transport will probably have already detected > failure and closed the connection. So the actual impact of the proposed >change on the example above probably isn't terribly significant - I'm OK >with the change. > > Jonathan It does change how one might wish to set the TWINIT value, though. For example, if you always wanted 30 second failover, setting TWINIT=30 seconds would get you that under the -06 algorithm, whereas on a heavily loaded network without proxies, you might need to set TWINIT=15 seconds with the -07 algorithm to get the same kind of performance. I'm not sure this is all that significant, though it is probably worth describing what the performance will be. I'm also OK with the change overall, because I think that decoupling failover on one hop from problems down the line is pretty important. With the old algorithm, it seems like you could get cascading instability. From owner-aaa-wg@merit.edu Thu Apr 11 23:52:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13484 for ; Thu, 11 Apr 2002 23:52:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0070691244; Thu, 11 Apr 2002 23:52:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C27F191245; Thu, 11 Apr 2002 23:52:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91A3A91244 for ; Thu, 11 Apr 2002 23:52:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 689315DE15; Thu, 11 Apr 2002 23:52:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B20B85DDA3 for ; Thu, 11 Apr 2002 23:51:59 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3C3qF528998 for ; Fri, 12 Apr 2002 06:52:15 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Apr 2002 06:51:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 06:51:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Fri, 12 Apr 2002 06:51:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EA0@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHhaEG5rpew1qI3THyg4yRrUBR5VgAbRfbw From: To: , Cc: , X-OriginalArrivalTime: 12 Apr 2002 03:51:58.0543 (UTC) FILETIME=[65365DF0:01C1E1D5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA13484 Hi Stephen, > > The only gotcha is when the TLS handshake fails. Do the > peers just fall > > back to non-secure operation? > > Eh - if so, why'd they bother trying to turn on TLS? Anyone > with access > to the network can tweak bits and cause the TLS handshake to fail, so > the answer to your question has to be a resounding "no". Agreed. John From owner-aaa-wg@merit.edu Fri Apr 12 00:53:48 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20625 for ; Fri, 12 Apr 2002 00:53:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB56C9124A; Fri, 12 Apr 2002 00:52:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B89749124D; Fri, 12 Apr 2002 00:52:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB3FA9124A for ; Fri, 12 Apr 2002 00:52:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 988BD5DE73; Fri, 12 Apr 2002 00:52:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 343CD5DDF5 for ; Fri, 12 Apr 2002 00:52:04 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g3C4rG4b023241; Fri, 12 Apr 2002 06:53:18 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "AAA Working Group" Subject: RE: [AAA-WG]: [ISSUE] key lifetime Date: Fri, 12 Apr 2002 06:50:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Siva, this is just poor configuration, if an administrator gives someone infinite lifetime on the session keys, it's bad configuration, and nothing that the protocol itself can do to prevent. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Sivasundar Ramamurthy >Sent: den 11 april 2002 00:00 >To: AAA Working Group >Subject: [AAA-WG]: [ISSUE] key lifetime > > > > >Submitter Name: Siva Ramamurthy >Submitter email address: sivasundar_ramamurthy@hp.com >Date first submitter: 3/27/2002 >Document: Mobile IP >Comment Type: T >Priority: 1 >Section: 1.6, 5.1, 6.13 > >Rationale/Explanation of Issue: > >Please bear with me for bringing this up again, for I dont want to >regret later that I did not! > >As I understand the draft, session Termination at the mobility agents >can be caused by two events: > >1. MN not re-authorizing before the auth lifetime expires > >2. Keys to the MN expiring > >Consider the scenario where the a MN is given keys for infite time (or >a value many time bigger that the authentication time) and an >authentication time of 300 secs. And during the course of roaming >around, the MN at some point is not able to re-authenticate itself (no >FA/co-located COA). This leads to termination of the session at the HA >and any sessions maintained for this MN by FA(s). Sometime later, the >MN does find that its way back to a previously visited FA and is able >to register without the need for requesting keys (which are still >alive). Since the MN does not include the MN-AAA auth ext, AAA cannot >be used and thus no new session can be created for the MN. So the FA >and HA provide services to the MN even while no session exists. > >I find nothing in the current standards that say that this is wrong or >not permissible, which probably means that there is nothing special to >handling this scenario and/or the standards provide the answers on >what to do. Can the WG please verify this? Thanks for the >consideration. > > >regards, > >Siva From owner-aaa-wg@merit.edu Fri Apr 12 05:33:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27056 for ; Fri, 12 Apr 2002 05:33:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A73B89124C; Fri, 12 Apr 2002 05:33:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E59E9124D; Fri, 12 Apr 2002 05:33:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB46B9124C for ; Fri, 12 Apr 2002 05:33:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90ADD5DDD4; Fri, 12 Apr 2002 05:33:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 8F6DE5DD8D for ; Fri, 12 Apr 2002 05:33:06 -0400 (EDT) Received: from BOA (a7.local.ipunplugged.com [192.168.4.177]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g3C9aA4b028026; Fri, 12 Apr 2002 11:36:11 +0200 Reply-To: From: "Bo Landarv" To: "Bernard Aboba" Cc: , , , Subject: RE: [AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise transport connection Date: Fri, 12 Apr 2002 11:31:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I am happy with the changes. I just have some comments/questions. * The base draft some versions ago made the distinction between Ti/Tr/Tw timer values. Maybe to separate Ti and Tr doesn't give that much, but how about the distinction between the time when to send the next DWR and when to expect a DWA? I think it might be useful to set different times for these. * In chapter 3.4.1 and Appendix A it says "Tw responses are pending", "watchdog responses are pending", "unanswered watchdog requests". Always in plural and not singular. Is this because you include retransmissions of lower protocol layers? I would have felt less confused with singular. * Chapter 3.4.1 item 2 "On sending a watchdog request, if no watchdog responses are pending, then Tw is reset." I get some bad vibrations here. Couldn't we say something like "On sending a watchdog request, Tw is reset" and "We only send a watchdog request when there is no watchdog response pending." * Appendix A. You switched the order of the functional approach and the state machine. Perfectly fine with me. * Appendix A. In the functional approach you have two assignments for variable Pending with "==". Should only be one = token. * Appendix A. Definition of Sendwatchdog(pcb) instead of SendWatchdog(pcb). * Appendix A. A new event Senddog was added. I don't think you need this nor the transitions for Senddog. SendWatchdog() does the job, doesn't it? That's all. /Bo Landarv > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: den 12 april 2002 00:58 > To: Bo Landarv > Cc: aaa-wg@merit.edu; randy@psg.com; mankin@isi.edu; > jonwood@speakeasy.net > Subject: Re: [AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise > transport connection > > > I've proposed new text in a "transport-07" strawman document to > address issue #334. The new version is available for inspection at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-07.txt > > Please let me know ASAP if the proposed text is satisfactory. > Substantial changes were required in section 3.4 as well as in > Appendix A to provide the fix, so that a careful read of the new text > would be appreciated. > > > From owner-aaa-wg@merit.edu Fri Apr 12 12:18:55 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13536 for ; Fri, 12 Apr 2002 12:18:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 547AC91253; Fri, 12 Apr 2002 12:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21B9A91259; Fri, 12 Apr 2002 12:18:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 126E291253 for ; Fri, 12 Apr 2002 12:17:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D80005DDF4; Fri, 12 Apr 2002 12:17:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id B93E35DDE1 for ; Fri, 12 Apr 2002 12:17:27 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 1297D400A24; Fri, 12 Apr 2002 09:17:25 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA20151; Fri, 12 Apr 2002 09:18:22 -0700 (PDT) Date: Fri, 12 Apr 2002 09:18:21 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: Tony Johansson , Johan Johansson , aaa-wg Subject: RE: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Fredrick, > Hi Siva, > > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Sivasundar Ramamurthy > >Sent: den 10 april 2002 02:11 > >To: Tony Johansson > >Cc: Johan Johansson; aaa-wg > >Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's > >security association with the FA > > > > > > > > > >Hi Tony, > > > >> As you state above this is not obvious in RFC3220. So, I strongly > >> suggest that people that really believe that this is needed first > >> gets this clarified in the mobile ip wg. I would hate to see that > >> we try to add functionality that may not really be ok according to > >> mobile ip and RFC3220. > > > >RFC3220 allows registering with the FA using a co-located address (R > >bit set in advertisement). This is a scenario where the COA (tunnel > >endpoint) is not the address of the FA's control interface. > > But if you use co-located care of address, you will not use an SA between > the CoA and HA, since the MN is already authenticated via the MN-HA Auth. > Ext. but is'nt the purpose of the FA-HA key to authenticate the entity that is forwarding the request, and not the COA? I think RFC3220 all but says that "when the MN uses a FA COA, that COA is also used as the src address of the request forwarded to the HA". In which case the forwarding entity = the COA. But this is not the case when the co-located MN is registering via the FA... Siva From owner-aaa-wg@merit.edu Fri Apr 12 12:33:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15858 for ; Fri, 12 Apr 2002 12:33:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D45291254; Fri, 12 Apr 2002 12:30:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C72DC91259; Fri, 12 Apr 2002 12:30:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67A8591254 for ; Fri, 12 Apr 2002 12:30:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40AEF5DDE1; Fri, 12 Apr 2002 12:30:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 0B4865DDBE for ; Fri, 12 Apr 2002 12:30:51 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3CGUoi28246 for ; Fri, 12 Apr 2002 11:30:50 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3CGUoi11663 for ; Fri, 12 Apr 2002 11:30:50 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA01620 for ; Fri, 12 Apr 2002 11:30:49 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA16306 for ; Fri, 12 Apr 2002 11:30:48 -0500 (CDT) Message-ID: <3CB70B03.57C07E3E@ericsson.com> Date: Fri, 12 Apr 2002 09:27:47 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Solution to issue #326 and #305 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, From all of the discussion made regarding issue #305 and #326. I've come to the following conclusions: * Adopt issue #305 with removing the MIP-Foriegn-Agent-Host AVP, since the spec does not specify any real use for it and no real need for it have been concluded. * Reject issue #326, since no one have really stated that this is needed or even allowed in mobile ip. Any comments / objections to this? /Tony From owner-aaa-wg@merit.edu Fri Apr 12 12:51:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18145 for ; Fri, 12 Apr 2002 12:51:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFD0E91304; Fri, 12 Apr 2002 12:51:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B722591305; Fri, 12 Apr 2002 12:51:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A747391304 for ; Fri, 12 Apr 2002 12:51:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C0385DE83; Fri, 12 Apr 2002 12:51:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 6D9555DE7A for ; Fri, 12 Apr 2002 12:51:34 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id F1AB6C005FF; Fri, 12 Apr 2002 09:51:33 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id JAA20229; Fri, 12 Apr 2002 09:52:31 -0700 (PDT) Date: Fri, 12 Apr 2002 09:52:30 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 In-Reply-To: <3CB70B03.57C07E3E@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, > * Reject issue #326, since no one have really stated that this is needed > or even allowed in mobile ip. The only scenario where we need the FA-address is when a co-located MN registers via the FA. Nothing in the standards say that the FA cannot create an AMR and request FA-HA keys in this case; and the HA cannot use the COA of the reg-request AVP to store the HA-FA key. thanks, Siva From owner-aaa-wg@merit.edu Fri Apr 12 13:05:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19915 for ; Fri, 12 Apr 2002 13:05:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFB2A91256; Fri, 12 Apr 2002 13:04:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A57F991305; Fri, 12 Apr 2002 13:04:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AB9391256 for ; Fri, 12 Apr 2002 13:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5ACDC5DE7A; Fri, 12 Apr 2002 13:04:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 2E9235DE79 for ; Fri, 12 Apr 2002 13:04:48 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id CBF41C0054E; Fri, 12 Apr 2002 10:04:47 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id KAA20290; Fri, 12 Apr 2002 10:05:45 -0700 (PDT) Date: Fri, 12 Apr 2002 10:05:44 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Fredrik Johansson Cc: AAA Working Group Subject: RE: [AAA-WG]: [ISSUE] key lifetime In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Fredrick, > this is just poor configuration, if an administrator gives someone infinite > lifetime on the session keys, it's bad configuration, and nothing that the > protocol itself can do to prevent. the example I gave you was mainly to convey this: We can run into scenarios when the MN can use AAA distributed keys (to the FA and the HA) and register even while the FA and HA cannot create seesions and account for this usage (as Joe pointed out). When the keys do expire, a new session can be created and usage can be accounted for. But the services provided prior to that cannot be accounted for. Dont we need to avoid this? thanks, Siva > > /Fredrik > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Sivasundar Ramamurthy > >Sent: den 11 april 2002 00:00 > >To: AAA Working Group > >Subject: [AAA-WG]: [ISSUE] key lifetime > > > > > > > > > >Submitter Name: Siva Ramamurthy > >Submitter email address: sivasundar_ramamurthy@hp.com > >Date first submitter: 3/27/2002 > >Document: Mobile IP > >Comment Type: T > >Priority: 1 > >Section: 1.6, 5.1, 6.13 > > > >Rationale/Explanation of Issue: > > > >Please bear with me for bringing this up again, for I dont want to > >regret later that I did not! > > > >As I understand the draft, session Termination at the mobility agents > >can be caused by two events: > > > >1. MN not re-authorizing before the auth lifetime expires > > > >2. Keys to the MN expiring > > > >Consider the scenario where the a MN is given keys for infite time (or > >a value many time bigger that the authentication time) and an > >authentication time of 300 secs. And during the course of roaming > >around, the MN at some point is not able to re-authenticate itself (no > >FA/co-located COA). This leads to termination of the session at the HA > >and any sessions maintained for this MN by FA(s). Sometime later, the > >MN does find that its way back to a previously visited FA and is able > >to register without the need for requesting keys (which are still > >alive). Since the MN does not include the MN-AAA auth ext, AAA cannot > >be used and thus no new session can be created for the MN. So the FA > >and HA provide services to the MN even while no session exists. > > > >I find nothing in the current standards that say that this is wrong or > >not permissible, which probably means that there is nothing special to > >handling this scenario and/or the standards provide the answers on > >what to do. Can the WG please verify this? Thanks for the > >consideration. > > > > > >regards, > > > >Siva > > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== From owner-aaa-wg@merit.edu Fri Apr 12 13:13:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21016 for ; Fri, 12 Apr 2002 13:13:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C0EC91305; Fri, 12 Apr 2002 13:13:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB7DF91308; Fri, 12 Apr 2002 13:13:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB3CB91305 for ; Fri, 12 Apr 2002 13:13:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97B825DE85; Fri, 12 Apr 2002 13:13:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 638AB5DE59 for ; Fri, 12 Apr 2002 13:13:11 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3CHDAi21797; Fri, 12 Apr 2002 12:13:10 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3CHD9X11120; Fri, 12 Apr 2002 12:13:09 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA05586; Fri, 12 Apr 2002 12:13:08 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA16969; Fri, 12 Apr 2002 12:13:07 -0500 (CDT) Message-ID: <3CB714EE.ACEE689A@ericsson.com> Date: Fri, 12 Apr 2002 10:10:06 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siva, Can you please elaborate this a bit further. I don't really understand your point here? /Tony Sivasundar Ramamurthy wrote: > Hi Tony, > > > * Reject issue #326, since no one have really stated that this is needed > > or even allowed in mobile ip. > > The only scenario where we need the FA-address is when a co-located MN > registers via the FA. Nothing in the standards say that the FA cannot > create an AMR and request FA-HA keys in this case; and the HA cannot > use the COA of the reg-request AVP to store the HA-FA key. > > thanks, > > Siva From owner-aaa-wg@merit.edu Fri Apr 12 13:25:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22737 for ; Fri, 12 Apr 2002 13:25:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6982491308; Fri, 12 Apr 2002 13:25:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34E4291309; Fri, 12 Apr 2002 13:25:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1ADB591308 for ; Fri, 12 Apr 2002 13:25:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E22E65DE85; Fri, 12 Apr 2002 13:25:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id C421A5DE59 for ; Fri, 12 Apr 2002 13:25:28 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 671B1C00BCD; Fri, 12 Apr 2002 10:25:28 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id KAA20358; Fri, 12 Apr 2002 10:26:26 -0700 (PDT) Date: Fri, 12 Apr 2002 10:26:24 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 In-Reply-To: <3CB714EE.ACEE689A@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, > Can you please elaborate this a bit further. I don't really understand your > point here? I'll try :-) The scenario is when a MN is using a co-located COA but needs to register via the FA since the 'r' bit is turned on in the advertisement (RFC3220). The MN includes a MN-AAA auth ext in the request, probably to renew the MN-HA key. The FA converts the request to an AMR, and adds a FA-HA key request since it does not have a key to the HA. When the HAR is receieved by the HA, it contains the FA-HA key but the key is not for the COA; The key is for the FA that sent the AMR. To HA needs to store the HA-FA key against the correct FA (IP address). This address cannot be obtained in the HAR and thus the Address AVP might be needed. I have thought through this for a while, and dont see anything that prevents this scenario from taking place. (NOTE: As I understand the HA-FA authentication by the HA, it is to authenticate the entity that forwarded the request (FA), not the COA in the request.) thanks, Siva From owner-aaa-wg@merit.edu Fri Apr 12 13:26:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22926 for ; Fri, 12 Apr 2002 13:26:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBEF591309; Fri, 12 Apr 2002 13:26:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A13299133F; Fri, 12 Apr 2002 13:26:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E99A91309 for ; Fri, 12 Apr 2002 13:26:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DF295DE87; Fri, 12 Apr 2002 13:26:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 0B50F5DE59 for ; Fri, 12 Apr 2002 13:26:44 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3CHQhi29810; Fri, 12 Apr 2002 12:26:43 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3CHQhX19756; Fri, 12 Apr 2002 12:26:43 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA06856; Fri, 12 Apr 2002 12:26:42 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA17178; Fri, 12 Apr 2002 12:26:41 -0500 (CDT) Message-ID: <3CB7181B.49DA6C5B@ericsson.com> Date: Fri, 12 Apr 2002 10:23:40 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Fredrik Johansson , AAA Working Group Subject: Re: [AAA-WG]: [ISSUE] key lifetime References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Siva, IMHO, this is more of deployment issues. We cannot really specify every possible bad configuration that can be made in the spec. I definitely agree with Fredrik below. /Tony Sivasundar Ramamurthy wrote: > Fredrick, > > > this is just poor configuration, if an administrator gives someone infinite > > lifetime on the session keys, it's bad configuration, and nothing that the > > protocol itself can do to prevent. > > the example I gave you was mainly to convey this: > > We can run into scenarios when the MN can use AAA distributed keys (to > the FA and the HA) and register even while the FA and HA cannot create > seesions and account for this usage (as Joe pointed out). When the > keys do expire, a new session can be created and usage can be > accounted for. But the services provided prior to that cannot be > accounted for. Dont we need to avoid this? > > thanks, > > Siva > > > > > /Fredrik > > >-----Original Message----- > > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > >Sivasundar Ramamurthy > > >Sent: den 11 april 2002 00:00 > > >To: AAA Working Group > > >Subject: [AAA-WG]: [ISSUE] key lifetime > > > > > > > > > > > > > > >Submitter Name: Siva Ramamurthy > > >Submitter email address: sivasundar_ramamurthy@hp.com > > >Date first submitter: 3/27/2002 > > >Document: Mobile IP > > >Comment Type: T > > >Priority: 1 > > >Section: 1.6, 5.1, 6.13 > > > > > >Rationale/Explanation of Issue: > > > > > >Please bear with me for bringing this up again, for I dont want to > > >regret later that I did not! > > > > > >As I understand the draft, session Termination at the mobility agents > > >can be caused by two events: > > > > > >1. MN not re-authorizing before the auth lifetime expires > > > > > >2. Keys to the MN expiring > > > > > >Consider the scenario where the a MN is given keys for infite time (or > > >a value many time bigger that the authentication time) and an > > >authentication time of 300 secs. And during the course of roaming > > >around, the MN at some point is not able to re-authenticate itself (no > > >FA/co-located COA). This leads to termination of the session at the HA > > >and any sessions maintained for this MN by FA(s). Sometime later, the > > >MN does find that its way back to a previously visited FA and is able > > >to register without the need for requesting keys (which are still > > >alive). Since the MN does not include the MN-AAA auth ext, AAA cannot > > >be used and thus no new session can be created for the MN. So the FA > > >and HA provide services to the MN even while no session exists. > > > > > >I find nothing in the current standards that say that this is wrong or > > >not permissible, which probably means that there is nothing special to > > >handling this scenario and/or the standards provide the answers on > > >what to do. Can the WG please verify this? Thanks for the > > >consideration. > > > > > > > > >regards, > > > > > >Siva > > > > > > Thanks, > > Siva > > ==================================== > Sivasundar Ramamurthy > (She-va-su-ndar Ra-ma-moor-thee) > > Engineer, Mobile IP Project > Hewlett Packard > (408) 447 7255 > ==================================== From owner-aaa-wg@merit.edu Sat Apr 13 22:48:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04143 for ; Sat, 13 Apr 2002 22:48:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31C1D91255; Sat, 13 Apr 2002 22:48:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01AD59125B; Sat, 13 Apr 2002 22:48:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BF6191255 for ; Sat, 13 Apr 2002 22:48:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D293E5DEA2; Sat, 13 Apr 2002 22:48:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 50AD65DD9E for ; Sat, 13 Apr 2002 22:48:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3E23gq10315; Sat, 13 Apr 2002 19:03:46 -0700 Date: Sat, 13 Apr 2002 19:03:41 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu, randy@psg.com, mankin@isi.edu, jonwood@speakeasy.net Subject: Re: [AAA-WG]: [issue 334] updated transport-07 text In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for the comments on the proposed transport-07 text. A new version reflecting the feedback is available for inspection at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-07.txt Comments welcome. From owner-aaa-wg@merit.edu Mon Apr 15 04:32:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10070 for ; Mon, 15 Apr 2002 04:32:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 862309121D; Mon, 15 Apr 2002 04:31:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98E7E9121F; Mon, 15 Apr 2002 04:31:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 578B59121D for ; Mon, 15 Apr 2002 04:31:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 272E65DD95; Mon, 15 Apr 2002 04:31:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 68B625DD8F for ; Mon, 15 Apr 2002 04:31:34 -0400 (EDT) Received: from BOA (a7.local.ipunplugged.com [192.168.4.177]) by mailgw.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3F8YoK0019580; Mon, 15 Apr 2002 10:34:51 +0200 Reply-To: From: "Bo Landarv" To: "Bernard Aboba" Cc: , , , Subject: RE: [AAA-WG]: [issue 334] updated transport-07 text Date: Mon, 15 Apr 2002 10:29:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I had one comment in my last mail which I would like to hear some reasoning about. The base draft originally made the distinction between Ti/Tr/Tw timer values. The transport draft only mentions Tw to do the job also of Ti/Tr. I think it would be a good idea to be able to set different timer values for interval when to probe the connection (Ti/Tr) and for when to require reception of a DWA answer (Tw). I could post this as an issue if you would like. /Bo > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: den 14 april 2002 04:04 > To: Bo Landarv > Cc: aaa-wg@merit.edu; randy@psg.com; mankin@isi.edu; > jonwood@speakeasy.net > Subject: Re: [AAA-WG]: [issue 334] updated transport-07 text > > > Thanks for the comments on the proposed transport-07 text. A new > version reflecting the feedback is available for inspection at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-07.txt > > Comments welcome. From owner-aaa-wg@merit.edu Mon Apr 15 05:34:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10806 for ; Mon, 15 Apr 2002 05:34:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C8BC9121F; Mon, 15 Apr 2002 05:34:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC69391224; Mon, 15 Apr 2002 05:34:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 959A49121F for ; Mon, 15 Apr 2002 05:34:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73D895DDBA; Mon, 15 Apr 2002 05:34:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 9B1AE5DD8F for ; Mon, 15 Apr 2002 05:34:05 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g3F8ap018759; Mon, 15 Apr 2002 10:36:52 +0200 Message-ID: <3CBA9E63.3070200@ipunplugged.com> Date: Mon, 15 Apr 2002 11:33:23 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: >1. Johan's comment (paraphrased as I understand it) that what is really >needed for issue#301 is for the AAAH to know the identity of the >destination AAAF hosting the foreign HA. Although by requiring a fixed >AAAH over the life of a MN's session, the AAAH can (with some effort) come >up with the AAAF's identity, why not instead have the MN cache the >destination AAAF's identity instead of the AAAH's identity? This >eliminates the seemingly unnecessary restriction, and single point of >failure, of a fixed AAAH. > Yes, this was my still unanswered question. >On the other hand, a single AAAH does have some modest virtues: >[a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new >SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't >change, the HA doesn't have to clear the session with the old AAAH when >a new AAAH comes on board; [c] does session/policy/resource management >become easier with a fixed AAAH? > I agree with all of the above but I strongly disagree that it is mandatory. They should all be perfectly allowable optimizations but mandating them is unnecessary, removes an interesting degree of freedom and most importantly forces external mechanisms to be used where none is needed. j From owner-aaa-wg@merit.edu Mon Apr 15 05:37:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10823 for ; Mon, 15 Apr 2002 05:37:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF87F91224; Mon, 15 Apr 2002 05:37:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F7E79125D; Mon, 15 Apr 2002 05:37:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7739991224 for ; Mon, 15 Apr 2002 05:37:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 542B85DDBA; Mon, 15 Apr 2002 05:37:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 7BDEB5DD8F for ; Mon, 15 Apr 2002 05:36:59 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3F9av130044; Mon, 15 Apr 2002 11:36:57 +0200 Message-ID: <3CBA9F14.40909@ipunplugged.com> Date: Mon, 15 Apr 2002 11:36:20 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 References: <3CB70B03.57C07E3E@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, What has happened with regard to issue #326 is that nobody has explained why it is *not* allowed in mobile ip, or maybe I have missed some emails. As I said, I'd be extatic to say that the CoA should always be used but I can not find any support for this in rfc 3220. j Tony Johansson wrote: >All, > >>From all of the discussion made regarding issue #305 and #326. I've come >to the following conclusions: > >* Adopt issue #305 with removing the MIP-Foriegn-Agent-Host AVP, since >the spec does not specify any real use for it and no real need for it >have been concluded. > >* Reject issue #326, since no one have really stated that this is needed >or even allowed in mobile ip. > >Any comments / objections to this? > >/Tony > From owner-aaa-wg@merit.edu Mon Apr 15 05:43:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10883 for ; Mon, 15 Apr 2002 05:43:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52FF19125D; Mon, 15 Apr 2002 05:43:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26F289125E; Mon, 15 Apr 2002 05:43:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A7649125D for ; Mon, 15 Apr 2002 05:43:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4AF35DDBA; Mon, 15 Apr 2002 05:43:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 25E245DD8F for ; Mon, 15 Apr 2002 05:43:02 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3F9h3511292 for ; Mon, 15 Apr 2002 12:43:03 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 12:42:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 12:42:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Date: Mon, 15 Apr 2002 12:42:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE0@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Thread-Index: AcHhTnUbVvhFSygDRAqU0sAUeTUH8wDEu44g From: To: , Cc: , , , X-OriginalArrivalTime: 15 Apr 2002 09:42:45.0239 (UTC) FILETIME=[E5429070:01C1E461] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA10883 Hi Harri, > I think that same applies to the ASR and STR commands. > See 8.4.1, 8.5.1 and 10.1. > > Regards.......Harri > | Command | > | Code | > |-----+-----+ > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 0-1 | 0-1 | Just to make sure: ACR, ACA, ASR & STR should all have: User-Name | 0-1 | 0-1 | is this correct? John From owner-aaa-wg@merit.edu Mon Apr 15 05:52:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10992 for ; Mon, 15 Apr 2002 05:52:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 946F39125E; Mon, 15 Apr 2002 05:52:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 664C19125F; Mon, 15 Apr 2002 05:52:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 399F09125E for ; Mon, 15 Apr 2002 05:52:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19DDE5DD8F; Mon, 15 Apr 2002 05:52:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3146E5DDBA for ; Mon, 15 Apr 2002 05:52:08 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3F9qO520268 for ; Mon, 15 Apr 2002 12:52:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 12:52:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 12:52:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Suggestion about hierarchical realms a poor one Date: Mon, 15 Apr 2002 12:52:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE2@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Suggestion about hierarchical realms a poor one Thread-Index: AcHgor60B38UUljeSQS6dPRclSIm9ADwGWaw From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2002 09:52:06.0928 (UTC) FILETIME=[340D8100:01C1E463] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA10992 Hi Johan, Do you suggest deleting all of section 6.1 or making a simplification of it? John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 10 April, 2002 17:32 > To: Johan Johansson > Cc: aaa-wg > Subject: Re: [AAA-WG]: Suggestion about hierarchical realms a poor one > > > Assigned Issue #328. > > On Sun, 7 Apr 2002, Johan Johansson wrote: > > > Issue: Suggestion about hierarchical realms a poor one > > Submitter name: Johan Johansson > > Submitter email address:johanj@ipunplugged.com > > Date first submitted: 04-09-2002 > > Reference: > > Document: draft-base-10-2 > > Comment type: Technical > > Priority: 1 > > Section: 6.1 > > > > Rationale: > > > > The suggestion is that > > > > > > For routing of Diameter messages to work within an administrative > > domain, all Diameter nodes within the realm MUST be peers. If > > intermediate nodes are desired (see Figure 5), the > destination node > > MUST be in a subrealm and routes to that subrealm MUST > exist in the > > routing table on the sending node and all intermediate > nodes. Figure > > 5 shows an example of a hierarchical network that > requires the use of > > subrealms. In such a network, routing must be performed > with longest > > match from right. > > > > Figure 5 then goes on to describe a realm abc.com with e.g. > a subrealm > > called eng.abc.com and a relay node in between. It may not > be obvious > > from the draft, but the original example discussed that > motivated this > > text and figure in the first place as within the context of > the mobile > > ip application where there was a home server in the > containing realm > > abc.com and the home agents within the respective subrealms. > > > > Assume that there is a user called john.doe@eng.abc.com > whose AMR is > > handled by the server aaah.abc.com. This is a centralized > home server > > that serves the entire realm abc.com and therefore it has a > route for > > abc.com that on longest match from right has a LOCAL_ACTION entry. > > Unfortunately this will never be selected since it must > have a route to > > eng.abc.com in order to send the HAR to the home agent, > which means that > > the AMR will arrive at a very surprised home agent. > > > > Requested change: > > > > Given the time constraints my suggestion is to fumble the issue and > > remove all mention of it from the document. Route configuration and > > network topology, within the context of the Mobile IP Diameter > > application at least, is a surprisingly non-intuitive topic. > > > > j > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Mon Apr 15 05:58:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11047 for ; Mon, 15 Apr 2002 05:58:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E5739125F; Mon, 15 Apr 2002 05:58:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E24D91261; Mon, 15 Apr 2002 05:58:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D72D9125F for ; Mon, 15 Apr 2002 05:58:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB7F25DDBA; Mon, 15 Apr 2002 05:58:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2B3EF5DD8F for ; Mon, 15 Apr 2002 05:58:21 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3F9wb525867 for ; Mon, 15 Apr 2002 12:58:37 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 12:58:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 12:58:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Message routing and vendor specific applications Date: Mon, 15 Apr 2002 12:58:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DA4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Message routing and vendor specific applications Thread-Index: AcHgtP+pCqKip9ykTf64FW4Cp76kRgDrl39w From: To: , X-OriginalArrivalTime: 15 Apr 2002 09:58:20.0008 (UTC) FILETIME=[126CFE80:01C1E464] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA11047 Hi Mark & Johan, What text would you like modified, there seems to be many places that could be modified. I have already taken your editorial suggest, however. John > -----Original Message----- > From: ext Mark Jones [mailto:mjones@bridgewatersystems.com] > Sent: 10 April, 2002 20:29 > To: aaa-wg > Subject: RE: [AAA-WG]: Message routing and vendor specific > applications > > > Hi Johan, > > I agree that message routing as described in the latest draft > does not take > into account vendor-specific applications. > > If I've correctly understood the requested change, the > Vendor-Id field would > be added to the Realm Routing Table Entry and if the > Application-Id field > contains the identifier of a IETF standard application, the > Vendor-ID field > MUST be set to zero (0). > > I also agree with the change suggested in your editorial side-issue. > > Regards, > Mark > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Johan Johansson > > Sent: April 10, 2002 1:29 PM > > To: Johan Johansson > > Cc: john.loughney@nokia.com; aaa-wg > > Subject: Re: [AAA-WG]: Message routing and vendor specific > applications > > > > > > Please, someone comment on this one. I am reluctant to make a change > > that nobody has reviewed. > > > > j > > > > Johan Johansson wrote: > > > > > Sure. I just want to get the issue reviewed first to make > sure I am > > > not seeing a problem where there is none and then I'd > want to see some > > > reaction to the solution alternatives I have suggested. > > > > > > j > > > > > > john.loughney@nokia.com wrote: > > > > > >> Johan, > > >> > > >> Do you want to supply the text? > > >> > > >> > > >> John > > >> > > >>> -----Original Message----- > > >>> From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > > >>> Sent: 07 April, 2002 18:35 > > >>> To: aaa-wg > > >>> Subject: [AAA-WG]: Message routing and vendor specific > applications > > >>> > > >>> > > >>> Issue: Message routing and vendor specific > > >>> applications > > >>> Submitter name: Johan Johansson > > >>> Submitter email address: johanj@ipunplugged.com > > >>> Date first submitted: 04-07-2002 Reference: > > >>> Document: Base Comment type: Technical > > >>> Priority: S Section: 2.7, 6.1, > 6.1.6, 6.10, > > >>> 9.7.1 > > >>> > > >>> Rationale/Explanation of issue: > > >>> > > >>> We allow vendor specific applications with their own > "namespaces" > > >>> but we do not perform routing on them. Section 6.1.6 > simply states: > > >>> > > >>> Diameter request message routing is done via realms. A Diameter > > >>> message that is able to be proxied MUST include the > target realm in > > >>> the Destination-Realm AVP. The realm MAY be retrieved > from the User- > > >>> Name AVP, which is in the form of a Network Access > Identifier (NAI). > > >>> The realm portion of the NAI is inserted in the > Destination-Realm > > >>> AVP. > > >>> > > >>> Diameter agents MAY have a list of locally supported > realms, and MAY > > >>> have a list of externally supported realms. When a request is > > >>> received that includes a realm that is not locally > supported, the > > >>> message is routed to the peer configured in the Realm > Routing Table > > >>> table (see section 2.8). > > >>> > > >>> On a side note this should probably be section 2.7, but the > > >>> important part is that nowhere in these paragraphs is > > >>> per-application routing mentioned, let alone > vendor-specific such. > > >>> > > >>> The preceding section 6.1 states > > >>> > > >>> The Destination-Realm AVP MUST be present if the message is > > >>> proxiable. Proxiable request messages MUST also > contain either an > > >>> Acct-Application-Id AVP or an Auth-Application-Id AVP. > > >>> > > >>> while 9.7.1 happily claims > > >>> > > >>> One of Acct-Application-Id and > Vendor-Specific-Application-Id AVPs > > >>> MUST be present. If the Vendor-Specific-Application-Id > > grouped AVP is > > >>> present, it must have an Acct-Application-Id inside. > > >>> > > >>> Pretty contradictory if you ask me. > > >>> > > >>> Finally, the section 2.7 describing the realm based > routing table says > > >>> > > >>> > > >>> - Application Identifier. A route entry can have a > different > > >>> destination based on the Acct-Application-Id for > accounting > > >>> messages) or Auth-Application-Id (for > non-accounting messages) > > >>> of the message. This field MUST be used as a secondary > > key field > > >>> in routing table lookups. > > >>> > > >>> It seems to me that it would need to use vendor id > *and* application > > >>> id to perform a proper lookup. > > >>> > > >>> Requested change: > > >>> > > >>> The solution is conceptually simple: make the routing > table store > > >>> vendor id and application id and add text to 6.1.6 to take these > > >>> into account when routing requests. > > >>> > > >>> We now have two ways to identify the application of a request. > > >>> Either it has a "naked" Acct/Auth-Application-Id *or* it has a > > >>> grouped Vendor-Specific-Application-Id AVP where the > Vendor-Id is > > >>> non-zero. Granted, the Diameter standard vendor is an important > > >>> special case but is it important enough to require a > two-stage lookup? > > >>> > > >>> What do you think? > > >>> > > >>> I'll sneak in an editorial side-issue. Shouldn't we change > > >>> > > >>> > > >>> 6.10 Vendor-Specific-Application-Id AVP > > >>> > > >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) > is of type > > >>> Grouped and is used to advertise support of a vendor-specific > > >>> Diameter Application. Either the Auth-Application-Id > or the Acct- > > >>> Application-Id AVP MAY be present. Exactly one of the Auth- > > >>> Application-Id and Acct-Application-Id AVPs MAY be present. > > >>> > > >>> to > > >>> > > >>> 6.10 Vendor-Specific-Application-Id AVP > > >>> > > >>> The Vendor-Specific-Application-Id AVP (AVP Code 260) > is of type > > >>> Grouped and is used to advertise support of a vendor-specific > > >>> Diameter Application. Exactly one of the Auth- > > >>> Application-Id and Acct-Application-Id AVPs MUST be present. > > >>> > > >>> j > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Mon Apr 15 06:00:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11070 for ; Mon, 15 Apr 2002 06:00:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 279B891261; Mon, 15 Apr 2002 06:00:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2EBC91263; Mon, 15 Apr 2002 06:00:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B4D0791261 for ; Mon, 15 Apr 2002 06:00:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB6C15DDDD; Mon, 15 Apr 2002 06:00:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 9DEEC5DD8F for ; Mon, 15 Apr 2002 06:00:04 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FA17J14169 for ; Mon, 15 Apr 2002 13:01:07 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:00:03 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:00:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Date: Mon, 15 Apr 2002 13:00:03 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE5@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Thread-Index: AcHgK0ind1O8xJ31SRqJBnL5ZgQoKQEOObNA From: To: , X-OriginalArrivalTime: 15 Apr 2002 10:00:03.0286 (UTC) FILETIME=[4FFBF760:01C1E464] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11070 Hi all, Any comments on the suggested solution? John ============== Minor corrections/clarifications to base-10 about Failed-AVP. I wonder, Is this can be Issue ? Regards, Byung-Gil Lee ETRI Information Security Technology Division Issue : What is Result Cause Value ? In multi-Failed AVP Case. Submitter name: BG Lee Submitter email address: bglee@etri.re.kr Date first submitted: 04-9-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: ? Section: 7.5 Failed-AVP AVP In section 7.5 Failed-AVP, 7.5 Failed-AVP AVP The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. ... but... Currently, there is no way to enter the two or more Reason Code in Result-Code AVP and it is difficult to match the Result-Code AVP and Failed-AVP. so... Existing : 7.5 Failed-AVP AVP AVP Format ::= < AVP Header: 279 > 1* {AVP} Requested change: AVP Format ::= < AVP Header: 279 > 1* { 1* {Result-Code AVP}/*Following AVP's Error Cause Value included*/ {AVP} } From owner-aaa-wg@merit.edu Mon Apr 15 06:01:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11109 for ; Mon, 15 Apr 2002 06:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35C1D91266; Mon, 15 Apr 2002 06:01:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 059B491264; Mon, 15 Apr 2002 06:01:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D11AF91263 for ; Mon, 15 Apr 2002 06:01:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B702C5DDDD; Mon, 15 Apr 2002 06:01:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 055AD5DD8F for ; Mon, 15 Apr 2002 06:01:18 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FA1Y528425 for ; Mon, 15 Apr 2002 13:01:34 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:01:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:01:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Mon, 15 Apr 2002 13:01:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE6@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHhDOiUaXpEZvywQBmrWuO2dr4XCQDV3lNA From: To: , X-OriginalArrivalTime: 15 Apr 2002 10:01:05.0871 (UTC) FILETIME=[7549ADF0:01C1E464] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11109 Hi All, I support this change, however, we should go about proposing a solution for this. Any takers? John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11 April, 2002 06:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [Issue 330]: Diameter should not require > separate TLS > port > > > Issue 330: Diameter should not require separate TLS port > Submitter name: Allison Mankin > Submitter email address: mankin@isi.edu > Date first submitted: 04-10-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: S > Section: 2.1 (contradicts section 13.3) > > Justification: The IESG is encouraging WGs to enable their > applications to negotiate an upgrade to TLS rather than requiring > a separate port. Diameter cannot yet handle this "startTLS" > up-negotiation. Do not assume that Diameter will be granted > an addition port for use with TLS. > > Change: > Need support for TLS up-negotiation in Diameter. > > > From owner-aaa-wg@merit.edu Mon Apr 15 06:02:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11128 for ; Mon, 15 Apr 2002 06:02:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A878B91264; Mon, 15 Apr 2002 06:02:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8402E91263; Mon, 15 Apr 2002 06:02:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E7A491269 for ; Mon, 15 Apr 2002 06:02:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 010BE5DDBA; Mon, 15 Apr 2002 06:02:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by segue.merit.edu (Postfix) with ESMTP id 4D6945DD8F for ; Mon, 15 Apr 2002 06:02:07 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FA25s7003919 for ; Mon, 15 Apr 2002 12:02:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 12:01:35 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTKPSY>; Mon, 15 Apr 2002 11:59:01 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA0301F947D7@efijont102> From: "Harri Hakala (LMF)" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Cc: "Victor Manuel Avila Gonzalez (ECE)" , "Tony Johansson (EUS)" , "Kevin Purser (EUS)" , "Carolina Canales Valenzuela (ECE)" Subject: RE: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Date: Mon, 15 Apr 2002 12:01:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, Yes, According to the ABNF definition of the STR and ASR commands (sections 8.4.1 and 8.5.1) there are stated that the User Name is optional. So ACR/ACA, ASR/ASA and STR/STA should all have: User-Name | 0-1 | 0-1 | / Harri -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 15. huhtikuuta 2002 12:43 To: Harri.Hakala@lmf.ericsson.se; aaa-wg@merit.edu Cc: victor-manuel.avila-gonzalez@ece.ericsson.se; Tony.Johansson@am1.ericsson.se; Kevin.Purser@am1.ericsson.se; carolina.canales-valenzuela@ece.ericsson.se Subject: RE: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Hi Harri, > I think that same applies to the ASR and STR commands. > See 8.4.1, 8.5.1 and 10.1. > > Regards.......Harri > | Command | > | Code | > |-----+-----+ > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > User-Name | 0-1 | 0-1 | Just to make sure: ACR, ACA, ASR & STR should all have: User-Name | 0-1 | 0-1 | is this correct? John From owner-aaa-wg@merit.edu Mon Apr 15 06:05:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11150 for ; Mon, 15 Apr 2002 06:05:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D75991263; Mon, 15 Apr 2002 06:05:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F61A91267; Mon, 15 Apr 2002 06:05:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0EF191263 for ; Mon, 15 Apr 2002 06:05:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8DD55DD8F; Mon, 15 Apr 2002 06:05:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 3DE685DDD9 for ; Mon, 15 Apr 2002 06:05:10 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3FA52510044; Mon, 15 Apr 2002 12:05:02 +0200 Message-ID: <3CBAA5AA.8020303@ipunplugged.com> Date: Mon, 15 Apr 2002 12:04:26 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Suggestion about hierarchical realms a poor one References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE2@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The suggestion is to delete the part of section 6.1 that relates to hierarchical nets, nothing else. The rest is probably correct. j john.loughney@nokia.com wrote: >Hi Johan, > >Do you suggest deleting all of section 6.1 or making a simplification >of it? > >John > >>-----Original Message----- >>From: ext Bernard Aboba [mailto:aboba@internaut.com] >>Sent: 10 April, 2002 17:32 >>To: Johan Johansson >>Cc: aaa-wg >>Subject: Re: [AAA-WG]: Suggestion about hierarchical realms a poor one >> >> >>Assigned Issue #328. >> >>On Sun, 7 Apr 2002, Johan Johansson wrote: >> >>>Issue: Suggestion about hierarchical realms a poor one >>>Submitter name: Johan Johansson >>>Submitter email address:johanj@ipunplugged.com >>>Date first submitted: 04-09-2002 >>>Reference: >>>Document: draft-base-10-2 >>>Comment type: Technical >>>Priority: 1 >>>Section: 6.1 >>> >>>Rationale: >>> >>>The suggestion is that >>> >>> >>>For routing of Diameter messages to work within an administrative >>> domain, all Diameter nodes within the realm MUST be peers. If >>> intermediate nodes are desired (see Figure 5), the >>> >>destination node >> >>> MUST be in a subrealm and routes to that subrealm MUST >>> >>exist in the >> >>> routing table on the sending node and all intermediate >>> >>nodes. Figure >> >>> 5 shows an example of a hierarchical network that >>> >>requires the use of >> >>> subrealms. In such a network, routing must be performed >>> >>with longest >> >>> match from right. >>> >>>Figure 5 then goes on to describe a realm abc.com with e.g. >>> >>a subrealm >> >>>called eng.abc.com and a relay node in between. It may not >>> >>be obvious >> >>>from the draft, but the original example discussed that >>> >>motivated this >> >>>text and figure in the first place as within the context of >>> >>the mobile >> >>>ip application where there was a home server in the >>> >>containing realm >> >>>abc.com and the home agents within the respective subrealms. >>> >>>Assume that there is a user called john.doe@eng.abc.com >>> >>whose AMR is >> >>>handled by the server aaah.abc.com. This is a centralized >>> >>home server >> >>>that serves the entire realm abc.com and therefore it has a >>> >>route for >> >>>abc.com that on longest match from right has a LOCAL_ACTION entry. >>>Unfortunately this will never be selected since it must >>> >>have a route to >> >>>eng.abc.com in order to send the HAR to the home agent, >>> >>which means that >> >>>the AMR will arrive at a very surprised home agent. >>> >>>Requested change: >>> >>>Given the time constraints my suggestion is to fumble the issue and >>>remove all mention of it from the document. Route configuration and >>>network topology, within the context of the Mobile IP Diameter >>>application at least, is a surprisingly non-intuitive topic. >>> >>>j >>> >>> >>> >>> >>> >>> >>> >>> >> > From owner-aaa-wg@merit.edu Mon Apr 15 06:08:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11189 for ; Mon, 15 Apr 2002 06:08:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56F6A91267; Mon, 15 Apr 2002 06:08:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F0A391268; Mon, 15 Apr 2002 06:08:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20B8691267 for ; Mon, 15 Apr 2002 06:08:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A12C5DDDC; Mon, 15 Apr 2002 06:08:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 941D05DD8F for ; Mon, 15 Apr 2002 06:08:04 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FA8K505075 for ; Mon, 15 Apr 2002 13:08:21 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Apr 2002 13:08:03 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:08:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 333 IANA references - closed Date: Mon, 15 Apr 2002 13:08:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE8@esebe004.NOE.Nokia.com> Thread-Topic: Issue 333 IANA references - closed Thread-Index: AcHkZW244B65d0NWTWSiuZZEX/jyEA== From: To: X-OriginalArrivalTime: 15 Apr 2002 10:08:03.0077 (UTC) FILETIME=[6DF64350:01C1E465] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11189 Hi all, Issue 333 IANA references has been corrected, the issue is now closed. John From owner-aaa-wg@merit.edu Mon Apr 15 06:09:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11216 for ; Mon, 15 Apr 2002 06:09:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE76491268; Mon, 15 Apr 2002 06:08:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 806A891269; Mon, 15 Apr 2002 06:08:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FD3D91268 for ; Mon, 15 Apr 2002 06:08:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46A715DDDC; Mon, 15 Apr 2002 06:08:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 89FD35DD8F for ; Mon, 15 Apr 2002 06:08:54 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FA9B505874 for ; Mon, 15 Apr 2002 13:09:11 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:08:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:08:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Date: Mon, 15 Apr 2002 13:08:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE9@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10) Thread-Index: AcHkZJpzdSEqsGY7SsSbC3uFroWgvAAAOFWQ From: To: , Cc: , , , X-OriginalArrivalTime: 15 Apr 2002 10:08:53.0385 (UTC) FILETIME=[8BF2A790:01C1E465] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11216 Hi Harri, > Yes, According to the ABNF definition of the STR and ASR commands > (sections 8.4.1 and 8.5.1) there are stated that the User Name > is optional. > > So ACR/ACA, ASR/ASA and STR/STA should all have: > > User-Name | 0-1 | 0-1 | That is what I thought, the correction has been made. John From owner-aaa-wg@merit.edu Mon Apr 15 06:10:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11246 for ; Mon, 15 Apr 2002 06:10:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2AE9991269; Mon, 15 Apr 2002 06:10:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEF1E9126A; Mon, 15 Apr 2002 06:10:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC98F91269 for ; Mon, 15 Apr 2002 06:10:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C564D5DD8F; Mon, 15 Apr 2002 06:10:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id DA7975DDDD for ; Mon, 15 Apr 2002 06:10:23 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FAAd507320 for ; Mon, 15 Apr 2002 13:10:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:10:20 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:10:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Suggestion about hierarchical realms a poor one Date: Mon, 15 Apr 2002 13:10:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EEA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Suggestion about hierarchical realms a poor one Thread-Index: AcHkZQcBW3lOtlGLTFumnupfeHCzjgAAKPxg From: To: Cc: , X-OriginalArrivalTime: 15 Apr 2002 10:10:20.0615 (UTC) FILETIME=[BFF0E570:01C1E465] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11246 Hi Johan, > The suggestion is to delete the part of section 6.1 that relates to > hierarchical nets, nothing else. The rest is probably correct. So, I shall delete this: For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers. If intermediate nodes are desired (see Figure 5), the destination node MUST be in a subrealm and routes to that subrealm MUST exist in the routing table on the sending node and all intermediate nodes. Figure 5 shows an example of a hierarchical network that requires the use of subrealms. In such a network, routing must be performed with longest match from right. .KS .nf +---------+ | abc.com | +---------+ +-------+ +-------+ | agent | | agent | +-------+ +-------+ +-------------+ +--------------+ +-------------+ +--------------+ | eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com | +-------------+ +--------------+ +-------------+ +--------------+ John From owner-aaa-wg@merit.edu Mon Apr 15 06:25:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12186 for ; Mon, 15 Apr 2002 06:25:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 440839126A; Mon, 15 Apr 2002 06:24:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11EC29126B; Mon, 15 Apr 2002 06:24:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED98E9126A for ; Mon, 15 Apr 2002 06:24:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C823D5DD8F; Mon, 15 Apr 2002 06:24:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 2C0835DDDC for ; Mon, 15 Apr 2002 06:24:57 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3FAOtw12629; Mon, 15 Apr 2002 12:24:55 +0200 Message-ID: <3CBAAA52.9000601@ipunplugged.com> Date: Mon, 15 Apr 2002 12:24:18 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Suggestion about hierarchical realms a poor one References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EEA@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for insisting on being unclear. john.loughney@nokia.com wrote: >Hi Johan, > >>The suggestion is to delete the part of section 6.1 that relates to >>hierarchical nets, nothing else. The rest is probably correct. >> > >So, I shall delete this: > >For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers. > Keep that sentence and delete the below. > If intermediate nodes are desired (see Figure 5), the destination node MUST be in a subrealm and routes to that subrealm MUST exist in the routing table on the sending node and all intermediate nodes. Figure 5 shows an example of a hierarchical network that requires the use of subrealms. In such a network, routing must be performed with longest match from right. > >.KS >.nf > +---------+ > | abc.com | > +---------+ > > +-------+ +-------+ > | agent | | agent | > +-------+ +-------+ > > +-------------+ +--------------+ +-------------+ +--------------+ > | eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com | > +-------------+ +--------------+ +-------------+ +--------------+ > j From owner-aaa-wg@merit.edu Mon Apr 15 06:32:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12354 for ; Mon, 15 Apr 2002 06:32:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA1949126B; Mon, 15 Apr 2002 06:31:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A0519126C; Mon, 15 Apr 2002 06:31:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08A879126B for ; Mon, 15 Apr 2002 06:31:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA16B5DDE0; Mon, 15 Apr 2002 06:31:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 1E1175DD8F for ; Mon, 15 Apr 2002 06:31:33 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FAVn526506 for ; Mon, 15 Apr 2002 13:31:49 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:31:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:31:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Suggestion about hierarchical realms a poor one Date: Mon, 15 Apr 2002 13:31:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EED@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Suggestion about hierarchical realms a poor one Thread-Index: AcHkZ8mBLvGKSUXSSySWV9owZxO9iwAAOVjQ From: To: Cc: , X-OriginalArrivalTime: 15 Apr 2002 10:31:31.0874 (UTC) FILETIME=[B5ABA020:01C1E468] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA12354 Hi Johan, > >For routing of Diameter messages to work within an > administrative domain, all Diameter nodes within the realm > MUST be peers. > > > Keep that sentence and delete the below. Done. John From owner-aaa-wg@merit.edu Mon Apr 15 06:33:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12388 for ; Mon, 15 Apr 2002 06:33:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCEFD9126C; Mon, 15 Apr 2002 06:33:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACCCA9126D; Mon, 15 Apr 2002 06:33:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 905429126C for ; Mon, 15 Apr 2002 06:33:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76AB85DDE0; Mon, 15 Apr 2002 06:33:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id BC1A15DD8F for ; Mon, 15 Apr 2002 06:33:15 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FAXW528016 for ; Mon, 15 Apr 2002 13:33:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 13:33:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 13:33:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #328 - closed Date: Mon, 15 Apr 2002 13:33:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EEE@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Suggestion about hierarchical realms a poor one Thread-Index: AcHgor60B38UUljeSQS6dPRclSIm9ADxh4XA From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2002 10:33:13.0594 (UTC) FILETIME=[F24CDDA0:01C1E468] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA12388 Hi all, > > Issue: Suggestion about hierarchical realms a poor one The text has now been fixed, issue closed. John From owner-aaa-wg@merit.edu Mon Apr 15 09:06:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16108 for ; Mon, 15 Apr 2002 09:06:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68CEF91227; Mon, 15 Apr 2002 09:06:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36C6D9126F; Mon, 15 Apr 2002 09:06:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CA0291227 for ; Mon, 15 Apr 2002 09:06:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23A935DDC7; Mon, 15 Apr 2002 09:06:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 9DED55DD8F for ; Mon, 15 Apr 2002 09:06:17 -0400 (EDT) Received: (qmail 11633 invoked by uid 500); 15 Apr 2002 13:06:17 -0000 Date: Mon, 15 Apr 2002 08:06:16 -0500 From: David Frascone To: john.loughney@nokia.com Cc: bglee@etri.re.kr, aaa-wg@merit.edu Subject: Re: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Message-ID: <20020415130616.GK11022@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, bglee@etri.re.kr, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE5@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE5@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I think that reporting and handling multiple errors is extremely difficult to do. I think for debugging, this would be a great feature. But, as far as full implementations go, it is not anything useful. It doesn't change the behavior of the protocol, just adds more work to handle the multiple errors. So, I vote "no". -Dave On Monday, 15 Apr 2002, john.loughney@nokia.com wrote: > Hi all, > > Any comments on the suggested solution? > > John > > ============== > > Minor corrections/clarifications to base-10 about Failed-AVP. > I wonder, Is this can be Issue ? > Regards, > Byung-Gil Lee > ETRI Information Security Technology Division > > > Issue : What is Result Cause Value ? In multi-Failed AVP Case. > Submitter name: BG Lee > Submitter email address: bglee@etri.re.kr > Date first submitted: 04-9-2002 > Reference: > Document: draft-base-10 > Comment type: Technical > Priority: ? > Section: 7.5 Failed-AVP AVP > > In section 7.5 Failed-AVP, > > 7.5 Failed-AVP AVP > > The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging > information in cases where a request is rejected or not fully processed due to > erroneous information in a specific AVP. The value of the Result-Code AVP will > provide information on the reason for the Failed-AVP AVP. > ... > > but... > Currently, there is no way to enter the two or more Reason Code in Result-Code AVP > and it is difficult to match the Result-Code AVP and Failed-AVP. > so... > > Existing : > > 7.5 Failed-AVP AVP > > AVP Format > ::= < AVP Header: 279 > > 1* {AVP} > > > Requested change: > > AVP Format > ::= < AVP Header: 279 > > 1* { > 1* {Result-Code AVP}/*Following AVP's Error Cause Value included*/ > {AVP} > } > -- David Frascone Chaste makes waste. From owner-aaa-wg@merit.edu Mon Apr 15 10:21:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18562 for ; Mon, 15 Apr 2002 10:21:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A143E9126F; Mon, 15 Apr 2002 10:18:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1509121C; Mon, 15 Apr 2002 10:18:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42DE59121C for ; Mon, 15 Apr 2002 10:18:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 280B85DDC7; Mon, 15 Apr 2002 10:18:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id CA91A5DDBA for ; Mon, 15 Apr 2002 10:18:14 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 07:18:14 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com'" , bglee@etri.re.kr, aaa-wg@merit.edu Subject: RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Ca se. Date: Mon, 15 Apr 2002 07:18:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E488.611536F0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E488.611536F0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this is overkill PatC - -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, April 15, 2002 3:00 AM To: bglee@etri.re.kr; aaa-wg@merit.edu Subject: RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Hi all, Any comments on the suggested solution? John ============== Minor corrections/clarifications to base-10 about Failed-AVP. I wonder, Is this can be Issue ? Regards, Byung-Gil Lee ETRI Information Security Technology Division Issue : What is Result Cause Value ? In multi-Failed AVP Case. Submitter name: BG Lee Submitter email address: bglee@etri.re.kr Date first submitted: 04-9-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: ? Section: 7.5 Failed-AVP AVP In section 7.5 Failed-AVP, 7.5 Failed-AVP AVP The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. ... but... Currently, there is no way to enter the two or more Reason Code in Result-Code AVP and it is difficult to match the Result-Code AVP and Failed-AVP. so... Existing : 7.5 Failed-AVP AVP AVP Format ::= < AVP Header: 279 > 1* {AVP} Requested change: AVP Format ::= < AVP Header: 279 > 1* { 1* {Result-Code AVP}/*Following AVP's Error Cause Value included*/ {AVP} } -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPLrhJTN1fXKoxmisEQLhqQCghLEFPY5iv+UA89ZpNXjUe91KaiMAn0Gc dAsBHEXCa92OsuGZGOGlYnQa =vBZr -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1E488.611536F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP = Case.

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this is overkill

PatC

- -----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Monday, April 15, 2002 3:00 AM
To: bglee@etri.re.kr; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: What is Result Cause Value ? = In Multi-Failed
AVP Case.


Hi all,

Any comments on the suggested solution?

John

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Minor corrections/clarifications to base-10 about = Failed-AVP.
I wonder, Is this can be Issue ?
Regards,
Byung-Gil Lee
ETRI Information Security Technology Division =
 

Issue = :            = ;     What is Result Cause Value ?  In = multi-Failed
AVP Case.
Submitter = name:         BG Lee
Submitter email address: bglee@etri.re.kr
Date first submitted:   04-9-2002
Reference:
Document:         =       draft-base-10
Comment = type:           = Technical
Priority:         =       ?
Section:         &= nbsp;           &= nbsp;  7.5  Failed-AVP AVP

In section 7.5 Failed-AVP,

7.5  Failed-AVP AVP

The Failed-AVP AVP (AVP Code 279) is of type Grouped = and provides
debugging
information in cases where a request is rejected or = not fully
processed due to
erroneous information in a specific AVP. The value = of the Result-Code
AVP will
provide information on the reason for the Failed-AVP = AVP.
...

but...
Currently, there is no way to enter the two or more = Reason Code in
Result-Code  AVP
and it is difficult to match the Result-Code AVP and = Failed-AVP.
so...

Existing :

7.5  Failed-AVP AVP

      AVP Format
      <Failed-AVP> = ::=3D < AVP Header: 279 >
          &nb= sp;         1* {AVP}


Requested change:

   AVP Format
    <Failed-AVP> ::=3D < AVP = Header: 279 >
          &nb= sp; 1* {
          &nb= sp;           1* = {Result-Code AVP}/*Following AVP's Error
Cause Value included*/
          &nb= sp;           &nb= sp;   {AVP}
          &nb= sp;       }

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPLrhJTN1fXKoxmisEQLhqQCghLEFPY5iv+UA89ZpNXjUe91KaiMAn0G= c
dAsBHEXCa92OsuGZGOGlYnQa
=3DvBZr
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1E488.611536F0-- From owner-aaa-wg@merit.edu Mon Apr 15 10:46:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19465 for ; Mon, 15 Apr 2002 10:46:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 353AC9121C; Mon, 15 Apr 2002 10:45:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F35CD9126E; Mon, 15 Apr 2002 10:45:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAF949121C for ; Mon, 15 Apr 2002 10:45:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C81215DDF1; Mon, 15 Apr 2002 10:45:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id D8A865DDE9 for ; Mon, 15 Apr 2002 10:45:49 -0400 (EDT) Received: (qmail 12864 invoked by uid 500); 15 Apr 2002 14:45:49 -0000 Date: Mon, 15 Apr 2002 09:45:49 -0500 From: David Frascone To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020415144549.GR11022@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE6@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE6@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Ok, here is my first cut at it. I'm sure I've missed a bit. Adding TLS handshaking is a pretty huge change. I did *not* modify the state machine, but added a cry for help (see the changes below) -Dave ------------snip---------------- Section 2.1 Remove the sentence: When used with TLS [TLS], the Diameter protocol is run on port TBD of both TCP and SCTP. Section 4.4, DiameterURI Since TLS is negotiated, I don't think any references to aaas make sense any more, so, remove the following lines: "aaas://" fqdn [ port ] [ transport ] [ protocol ] . . . aaas://host.abc.com;transport=tcp aaas://host.abc.com;protocol=diameter Section 5.2, item 3 & 3.x [snip] 3.1 The services relevant for the task of transport protocol selection are those with NAPTR service fields with values *** "AAA+D2x", where x is a letter that corresponds to a transport protocol supported by the domain. [snip] **** delete section 3.2 3.2[was 3.3] If no NAPTR records are found, the requester queries for those address records for the destination address, ***** '_diameter._sctp'.realm or '_diameter._tcp'.realm. Addressrecords include A RR's, AAAA RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. ***** If the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. Section 5.3 [from first paragraph] state machine (see section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security model, etc.) [snip] A receiver of a Capabilities-Exchange-Req (CER) message that does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a Relay (see section 2.4) MUST be interpreted as having common applications with the peer. *** Similarly, a receiver of a Capabilities-Exchange-Req (CER) message that does not have any security model in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the transport layer connection. Section 5.3.1 Capabilities-Exchange-Request ::= < Diameter Header: 257, REQ > { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] ***** * [ Inband-Security-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] Section 5.3.2 Capabilities-Exchange-Answer ::= < Diameter Header: 257 > { Result-Code } { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] [ Error-Message ] * [ Failed-AVP ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] ***** * [ Inband-Security-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ] Section 5.6 Can someone help me here? Do we really want to complicate the state machine by adding all the "If both ends support it, we do TLS now" states, or should we just add a section 5.6.5 describing that a TLS handshake will begin when both ends are in the open state, and all further messages will be sent via TLS? New Section 6.10 (bump the others) 6.10 Inband-Security-Id The Inband-Security-Id AVP (AVP Code TBD) is of type Unsigned32 and is used in order to advertise support of the Security portion of the application. Currently, the following values are supported, but there is ample room to add new security Ids. NO_SECURITY 0 This peer does not support any security model. This is the default value, if the AVP is omitted. TLS 1 This node supports TLS security, as defined by [TLS]. Section 11.15 Delete the following lines: The following values are to be placed into the registry: Services Field Protocol AAA+D2T TCP AAAS+D2T TLS over TCP AAA+D2S SCTP AAAS+D2S TLS over SCTP Apendix B. NAPTR Example Delete all examples with AAAS. Result should look like: ;; order pref flags service regexp replacement _diameters._sctp.ex.com. IN NAPTR 50 50 "s" "AAA+D2S" "" _diameters._tcp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.ex.com This indicates that the server supports SCTP and TCP, in that order. If the client supports SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of _diameters._sctp.ex.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.ex.com IN SRV 0 2 5060 server2.ex.com On Monday, 15 Apr 2002, john.loughney@nokia.com wrote: > Hi All, > > I support this change, however, we should go about proposing a > solution for this. Any takers? > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 11 April, 2002 06:13 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: [Issue 330]: Diameter should not require > > separate TLS > > port > > > > > > Issue 330: Diameter should not require separate TLS port > > Submitter name: Allison Mankin > > Submitter email address: mankin@isi.edu > > Date first submitted: 04-10-2002 > > Reference: > > Document: draft-base-10 > > Comment type: Technical > > Priority: S > > Section: 2.1 (contradicts section 13.3) > > > > Justification: The IESG is encouraging WGs to enable their > > applications to negotiate an upgrade to TLS rather than requiring > > a separate port. Diameter cannot yet handle this "startTLS" > > up-negotiation. Do not assume that Diameter will be granted > > an addition port for use with TLS. > > > > Change: > > Need support for TLS up-negotiation in Diameter. > > > > > > > -- David Frascone (C) 1992 Wild Bill's Machine Gun Shop and House of Wax. From owner-aaa-wg@merit.edu Mon Apr 15 10:49:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19504 for ; Mon, 15 Apr 2002 10:49:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E56E9126E; Mon, 15 Apr 2002 10:48:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A2C691270; Mon, 15 Apr 2002 10:48:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A57F9126E for ; Mon, 15 Apr 2002 10:48:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D50D5DDE9; Mon, 15 Apr 2002 10:48:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A10DB5DDC7 for ; Mon, 15 Apr 2002 10:48:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3FE4QI19499; Mon, 15 Apr 2002 07:04:26 -0700 Date: Mon, 15 Apr 2002 07:04:26 -0700 (PDT) From: Bernard Aboba To: Bo Landarv Cc: aaa-wg@merit.edu, randy@psg.com, mankin@isi.edu, jonwood@speakeasy.net Subject: RE: [AAA-WG]: [issue 334] updated transport-07 text In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk As long as a connection remains open, a reliable transport will retransmit an outstanding segment. Since the transport handles retransmissions, it doesn't make sense for the watchdog to be retransmitted at the application layer. Thus, if there were separate timers for the "waiting interval" and the "time between watchdogs" the reality would still be that the watchdog was being continually retransmitted until the connection was closed. Moreover, research such as [Paxson] shows that in practice, substantial "waiting intervals" are required to assure against spurious failover. For example, route oscillations may persist as long as 30 seconds. That means that in practice the "waiting interval" and the time between watchdogs are of the same order. Since the "waiting interval" is of the same order as the "watchdog" interval, in order to reduce the complexity of the algorithm, multiple timers were eliminated. On Mon, 15 Apr 2002, Bo Landarv wrote: > > I had one comment in my last mail which I would like to hear some > reasoning about. > > The base draft originally made the distinction between Ti/Tr/Tw > timer values. The transport draft only mentions Tw to do the job > also of Ti/Tr. > > I think it would be a good idea to be able to set different timer > values for interval when to probe the connection (Ti/Tr) and > for when to require reception of a DWA answer (Tw). > > I could post this as an issue if you would like. > > /Bo > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Bernard Aboba > > Sent: den 14 april 2002 04:04 > > To: Bo Landarv > > Cc: aaa-wg@merit.edu; randy@psg.com; mankin@isi.edu; > > jonwood@speakeasy.net > > Subject: Re: [AAA-WG]: [issue 334] updated transport-07 text > > > > > > Thanks for the comments on the proposed transport-07 text. A new > > version reflecting the feedback is available for inspection at: > > > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-07.txt > > > > Comments welcome. > From owner-aaa-wg@merit.edu Mon Apr 15 15:20:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03638 for ; Mon, 15 Apr 2002 15:20:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8349E91275; Mon, 15 Apr 2002 15:20:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 593D591276; Mon, 15 Apr 2002 15:20:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3ECC291275 for ; Mon, 15 Apr 2002 15:20:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B21B5DDEF; Mon, 15 Apr 2002 15:20:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id AF79D5DD92 for ; Mon, 15 Apr 2002 15:20:09 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id PAA29693 for ; Mon, 15 Apr 2002 15:20:44 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id PAA07116 for ; Mon, 15 Apr 2002 15:22:29 -0400 (EDT) From: "Mark Jones" To: Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications Date: Mon, 15 Apr 2002 15:22:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DA4@esebe004.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > What text would you like modified, there seems to be many places > that could be modified. Assuming we're still going to refer to this as 'Realm-based' routing, I think that there are two sections that need to be modified: Section 2.7: Add the vendor-id to the realm based routing table. Are there any objections to re-using the existing application id field in the Realm-based Routing Table to store a vendor-specific application id? Section 6.1: Change "Proxiable request messages MUST also contain either an Acct-Application-Id AVP or an Auth-Application-Id AVP." to "Proxiable request messages MUST also contain either an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP." Regards, Mark From owner-aaa-wg@merit.edu Mon Apr 15 15:50:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04632 for ; Mon, 15 Apr 2002 15:50:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1CF5091276; Mon, 15 Apr 2002 15:50:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E505C91277; Mon, 15 Apr 2002 15:50:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEE3891276 for ; Mon, 15 Apr 2002 15:50:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C32005DD98; Mon, 15 Apr 2002 15:50:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 0164D5DD92 for ; Mon, 15 Apr 2002 15:50:15 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020415195014.ZKLB12824.fep01-svc.swip.net@ipunplugged.com>; Mon, 15 Apr 2002 21:50:14 +0200 Message-ID: <3CBB2F45.9000801@ipunplugged.com> Date: Mon, 15 Apr 2002 21:51:33 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Jones Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific applications References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Jones wrote: >>What text would you like modified, there seems to be many places >>that could be modified. >> > >Assuming we're still going to refer to this as 'Realm-based' routing, I >think that there are two sections that need to be modified: > >Section 2.7: Add the vendor-id to the realm based routing table. Are there >any objections to re-using the existing application id field in the >Realm-based Routing Table to store a vendor-specific application id? > The main objection is that vendor applications may have the same id as standard application since they do not share the same "numberspace", i.e. the vendor/app pair (0, 4) would identify the mobile ip application while (5902, 4) would identify vendor 5902's application 4.. >Section 6.1: Change "Proxiable request messages MUST also contain either an >Acct-Application-Id AVP or an Auth-Application-Id AVP." to "Proxiable >request messages MUST also contain either an Acct-Application-Id AVP, an >Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP." > Seems reasonable. I am working on a more complete suggestion that I will fire off within the next few hours. j From owner-aaa-wg@merit.edu Mon Apr 15 17:07:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06758 for ; Mon, 15 Apr 2002 17:07:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 007989120E; Mon, 15 Apr 2002 17:07:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C2291212; Mon, 15 Apr 2002 17:07:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE15E9120E for ; Mon, 15 Apr 2002 17:07:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90CE75DE0B; Mon, 15 Apr 2002 17:07:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 43BDC5DDDE for ; Mon, 15 Apr 2002 17:07:36 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA30615; Mon, 15 Apr 2002 17:08:11 -0400 Received: from PRESTON ([192.168.149.28]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id RAA18915; Mon, 15 Apr 2002 17:09:55 -0400 (EDT) From: "Mark Jones" To: "Johan Johansson" Cc: Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications Date: Mon, 15 Apr 2002 17:11:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CBB2F45.9000801@ipunplugged.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >Section 2.7: Add the vendor-id to the realm based routing table. > Are there > >any objections to re-using the existing application id field in the > >Realm-based Routing Table to store a vendor-specific application id? > > > The main objection is that vendor applications may have the same id as > standard application since they do not share the same "numberspace", > i.e. the vendor/app pair (0, 4) would identify the mobile ip application > while (5902, 4) would identify vendor 5902's application 4.. > Agreed but the realm table entry is unambiguous if it contains both the vendor-id (zero for IETF apps) and an application id. Both these fields must be used together with the realm in selecting the destination host. Anyway, rather than trying to second-guess, I'll wait for your proposed text for section 2.7 :) Regards, Mark From owner-aaa-wg@merit.edu Mon Apr 15 18:47:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08859 for ; Mon, 15 Apr 2002 18:47:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB66C91212; Mon, 15 Apr 2002 18:47:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 895E091279; Mon, 15 Apr 2002 18:47:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B040691212 for ; Mon, 15 Apr 2002 18:47:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88CEE5DE8C; Mon, 15 Apr 2002 18:47:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id EB7955DE0D for ; Mon, 15 Apr 2002 18:47:23 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020415224723.SUCT23157.fep03-svc.swip.net@ipunplugged.com>; Tue, 16 Apr 2002 00:47:23 +0200 Message-ID: <3CBB58C9.3030803@ipunplugged.com> Date: Tue, 16 Apr 2002 00:48:41 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Jones Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific applications References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Jones wrote: >>The main objection is that vendor applications may have the same id as >>standard application since they do not share the same "numberspace", >>i.e. the vendor/app pair (0, 4) would identify the mobile ip application >>while (5902, 4) would identify vendor 5902's application 4.. >> >Agreed but the realm table entry is unambiguous if it contains both the >vendor-id (zero for IETF apps) and an application id. Both these fields must >be used together with the realm in selecting the destination host. > That's exactly what I was after. >Anyway, rather than trying to second-guess, I'll wait for your proposed text >for section 2.7 :) > And here, eventually, it is. Please improve phrasing and point out misconceptions. Also, I'm sure the those with more practice in rfc-ese will want to change the capitilization of some words. 2.7 - minimally change: - Application Identifier. A route entry can have a different destination based on the Acct-Application-Id for accounting messages) or Auth-Application-Id (for non-accounting messages) of the message. This field MUST be used as a secondary key field in routing table lookups. to ---------- - Application Identifier. An application is identified by a vendor id and an application id. If the application is one defined by the Diameter workgroup the vendor id is 0. A route entry can have a different destination based on the Acct-Application-Id (for accounting messages) or Auth-Application-Id (for non-accounting messages) of the message. This field MUST be used as a secondary key field in routing table lookups. ----------- (bonus question: does this mean that accounting routes and authorization routes for the same application can not differ?) For 6.1 and 6.1.6 only Mark has stated an opinion, but based on gut feeling and Mark's emails I am suggesting that the optimized way of using simply the Axxx-Application-Ids for non-vendor applications is retained. Thus the relevant part of 6.1 that was The Destination-Realm AVP MUST be present if the message is proxiable. Proxiable request messages MUST also contain either an Acct-Application-Id AVP or an Auth-Application-Id AVP. becomes ---------- The Destination-Realm AVP MUST be present if the message is proxiable. Proxiable request messages MUST also contain an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP. ---------- while 6.1.6 (relevant part) was Diameter request message routing is done via realms. A Diameter message that is able to be proxied MUST include the target realm in the Destination-Realm AVP. The realm MAY be retrieved from the User- Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Diameter agents MAY have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Realm Routing Table table (see section 2.8). I suggest changing it to, although it is a bit redundant with regard to 6.1: ---------- Diameter request message routing is done via realms and applications. A Diameter message that is able to be proxied MUST include the target realm in the Destination-Realm AVP and one of the application identification AVPs Auth-Application-Id, Acct-Application-Id or Vendor-Specific-Application-Id. The realm MAY be retrieved from the User- Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Diameter agents MAY have a list of locally supported realms and applications, and MAY have a list of externally supported realms and applications. When a request is received that includes a realm and/or application that is not locally supported, the message is routed to the peer configured in the Realm Routing Table table (see section 2.7). --------- I think 9.7.1 is ok as is with the change to 6.1. j From owner-aaa-wg@merit.edu Mon Apr 15 18:52:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09003 for ; Mon, 15 Apr 2002 18:52:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31E839127B; Mon, 15 Apr 2002 18:52:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFE059127C; Mon, 15 Apr 2002 18:52:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7A299127B for ; Mon, 15 Apr 2002 18:52:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D07745DE8C; Mon, 15 Apr 2002 18:52:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 3F22B5DE0D for ; Mon, 15 Apr 2002 18:52:35 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020415225234.BKC12824.fep01-svc.swip.net@ipunplugged.com>; Tue, 16 Apr 2002 00:52:34 +0200 Message-ID: <3CBB5A01.9010707@ipunplugged.com> Date: Tue, 16 Apr 2002 00:53:53 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johan Johansson Cc: Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific applications References: <3CBB58C9.3030803@ipunplugged.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > 2.7 - minimally change: > > - Application Identifier. A route entry can have a different > destination based on the Acct-Application-Id for accounting > messages) or Auth-Application-Id (for non-accounting messages) > of the message. This field MUST be used as a secondary key field > in routing table lookups. > > to > > ---------- > > - Application Identifier. An application is identified by a vendor id > and an application id. If the application is one defined by the > Diameter workgroup the vendor id is 0. A route entry can have a different > destination based on the Acct-Application-Id (for accounting > messages) or Auth-Application-Id (for non-accounting messages) > of the message. This field MUST be used as a secondary key field > in routing table lookups. > > ----------- Actually on second thought we should probably even change it to ---------- - Application Identifier. An application is identified by a vendor id and an application id. If the application is one defined by the Diameter workgroup the vendor id is 0. A route entry can have a different destination based on the application identification avp of the message. This is one of Acct-Application-Id (for accounting messages), Auth-Application-Id (for non-accounting messages) or Vendor-Specific-Application-Id (for vendor specific messages). This field MUST be used as a secondary key field in routing table lookups. ----------- j From owner-aaa-wg@merit.edu Tue Apr 16 03:11:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25393 for ; Tue, 16 Apr 2002 03:11:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66DEA91226; Tue, 16 Apr 2002 03:11:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1928C91229; Tue, 16 Apr 2002 03:11:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CCD591226 for ; Tue, 16 Apr 2002 03:11:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29C065DD98; Tue, 16 Apr 2002 03:11:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 39AAF5DD92 for ; Tue, 16 Apr 2002 03:11:39 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G7Aju15407 for ; Tue, 16 Apr 2002 10:10:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Apr 2002 10:11:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 10:11:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications Date: Tue, 16 Apr 2002 10:11:37 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F22@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #327: Message routing and vendor specific applications Thread-Index: AcHk0EeaUsA1X85dTVeZqFuPF/eJfgARZqfQ From: To: Cc: , X-OriginalArrivalTime: 16 Apr 2002 07:11:37.0961 (UTC) FILETIME=[F3277D90:01C1E515] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25393 Hi Johan, > Actually on second thought we should probably even change it to > > ---------- > > - Application Identifier. An application is identified by a vendor id > and an application id. If the application is one defined by > the Diameter > workgroup the vendor id is 0. A route entry can have a different > destination based on the application identification avp of > the message. > This is one of Acct-Application-Id (for accounting > messages), Auth-Application-Id (for non-accounting messages) or > Vendor-Specific-Application-Id (for vendor specific messages). This > field MUST be used as a secondary key field > in routing table lookups. I think this is OK. John From owner-aaa-wg@merit.edu Tue Apr 16 03:18:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25498 for ; Tue, 16 Apr 2002 03:18:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6E0C91229; Tue, 16 Apr 2002 03:17:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98AE49122A; Tue, 16 Apr 2002 03:17:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E16391229 for ; Tue, 16 Apr 2002 03:17:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FEC25DD98; Tue, 16 Apr 2002 03:17:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 5A4DB5DD92 for ; Tue, 16 Apr 2002 03:17:57 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3G7Hu3G019060 for ; Tue, 16 Apr 2002 09:17:56 +0200 (MEST) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 16 09:17:53 2002 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 09:17:53 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED211F@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Result codes in vendor specific applications Date: Tue, 16 Apr 2002 09:17:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I haven't found any statement in the base regarding the management of Result-Codes in vendor specific applications. I assume that a vendor specific application can assign its own result codes. Is my understanding correct? If so and if there is consensus in the list I am happy to provide the (small) required changes. Best regards, Miguel From owner-aaa-wg@merit.edu Tue Apr 16 03:20:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25532 for ; Tue, 16 Apr 2002 03:20:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1A2E9122A; Tue, 16 Apr 2002 03:19:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A56A89122B; Tue, 16 Apr 2002 03:19:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 520ED9122A for ; Tue, 16 Apr 2002 03:19:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B0735DD98; Tue, 16 Apr 2002 03:19:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 39D055DD92 for ; Tue, 16 Apr 2002 03:19:56 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G7KtJ03088 for ; Tue, 16 Apr 2002 10:20:59 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Apr 2002 10:19:49 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 10:19:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications Date: Tue, 16 Apr 2002 10:19:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DA9@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #327: Message routing and vendor specific applications Thread-Index: AcHkz5ITHH8C93apSkyU4YMvIsK8kgARs6zg From: To: , Cc: X-OriginalArrivalTime: 16 Apr 2002 07:19:49.0113 (UTC) FILETIME=[17E75690:01C1E517] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25532 Hi Johan, > For 6.1 and 6.1.6 only Mark has stated an opinion, but based on gut > feeling and Mark's emails I am suggesting that the optimized way of > using simply the Axxx-Application-Ids for non-vendor applications is > retained. Thus the relevant part of 6.1 that was > > The Destination-Realm AVP MUST be present if the message is > proxiable. Proxiable request messages MUST also contain either an > Acct-Application-Id AVP or an Auth-Application-Id AVP. > > becomes > > ---------- > > The Destination-Realm AVP MUST be present if the message is > proxiable. Proxiable request messages MUST also contain an > Acct-Application-Id AVP, an Auth-Application-Id AVP or a > Vendor-Specific-Application-Id AVP. I think this change is OK. > while 6.1.6 (relevant part) was > > Diameter request message routing is done via realms. A Diameter > message that is able to be proxied MUST include the target realm in > the Destination-Realm AVP. The realm MAY be retrieved from > the User- > Name AVP, which is in the form of a Network Access > Identifier (NAI). > The realm portion of the NAI is inserted in the Destination-Realm > AVP. > > Diameter agents MAY have a list of locally supported > realms, and MAY > have a list of externally supported realms. When a request is > received that includes a realm that is not locally supported, the > message is routed to the peer configured in the Realm Routing Table > table (see section 2.8). > > I suggest changing it to, although it is a bit redundant with > regard to 6.1: > > ---------- > > Diameter request message routing is done via realms and > applications. A > Diameter > message that is able to be proxied MUST include the target realm in > the Destination-Realm AVP and one of the application > identification AVPs > Auth-Application-Id, Acct-Application-Id or > Vendor-Specific-Application-Id. The realm MAY be retrieved > from the User- > Name AVP, which is in the form of a Network Access Identifier (NAI). > The realm portion of the NAI is inserted in the Destination-Realm > AVP. > > Diameter agents MAY have a list of locally supported realms and > applications, and MAY > have a list of externally supported realms and applications. When a > request is > received that includes a realm and/or application that is not locally > supported, the > message is routed to the peer configured in the Realm Routing Table > table (see section 2.7). I think this is OK as well, the redundancy is not a problem, in my mind. I think this should close out this issue? John From owner-aaa-wg@merit.edu Tue Apr 16 03:47:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25877 for ; Tue, 16 Apr 2002 03:47:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 511639122B; Tue, 16 Apr 2002 03:47:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D0BF91271; Tue, 16 Apr 2002 03:47:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A974A9122B for ; Tue, 16 Apr 2002 03:47:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8121B5DDE3; Tue, 16 Apr 2002 03:47:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id B3D185DD92 for ; Tue, 16 Apr 2002 03:47:11 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G7mAJ17412 for ; Tue, 16 Apr 2002 10:48:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Apr 2002 10:47:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 10:47:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Tue, 16 Apr 2002 10:47:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHkjD5VjeiO03toSd65MfF2X6BJVAAixokw From: To: Cc: , X-OriginalArrivalTime: 16 Apr 2002 07:47:06.0234 (UTC) FILETIME=[E7B42DA0:01C1E51A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25877 Hi David, Thanks for the changes, comments in-line: > Section 2.1 > Remove the sentence: > When used with TLS [TLS], the Diameter protocol is run on port TBD of > both TCP and SCTP. Agreed. > Section 4.4, DiameterURI > > Since TLS is negotiated, I don't think any references to aaas make sense any more, > so, remove the following lines: > > "aaas://" fqdn [ port ] [ transport ] [ protocol ] > . . . > aaas://host.abc.com;transport=tcp > aaas://host.abc.com;protocol=diameter Agreed. > Section 5.2, item 3 & 3.x I agree with most of your changes, but I've kept section 3.2, but edited it to be: 3.2 A client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query. > Section 5.3 > > [from first paragraph] > state machine (see section 5.6). This message allows the discovery of > a peer's identity and its capabilities (protocol version number, > supported Diameter applications, security model, etc.) ^^^^^^^^^^^^^^ The avove is new only new text, correct? > A receiver of a Capabilities-Exchange-Req (CER) message that does not > have any applications in common with the sender MUST return a > Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to > DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport > layer connection. Note that receiving a CER or CEA from a peer > advertising itself as a Relay (see section 2.4) MUST be interpreted > as having common applications with the peer. > > *** Similarly, a receiver of a Capabilities-Exchange-Req (CER) message > that does not have any security model in common with the sender MUST > return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP > set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the transport > layer connection. I agree with this. > Section 5.3.1 Capabilities-Exchange-Request > > ::= < Diameter Header: 257, REQ > > { Origin-Host } > { Origin-Realm } > 1* { Host-IP-Address } > { Vendor-Id } > { Product-Name } > [ Origin-State-Id ] > * [ Supported-Vendor-Id ] > * [ Auth-Application-Id ] > ***** * [ Inband-Security-Id ] > * [ Acct-Application-Id ] > * [ Vendor-Specific-Application-Id ] > [ Firmware-Revision ] > * [ AVP ] > > Section 5.3.2 Capabilities-Exchange-Answer > > ::= < Diameter Header: 257 > > { Result-Code } > { Origin-Host } > { Origin-Realm } > 1* { Host-IP-Address } > { Vendor-Id } > { Product-Name } > [ Origin-State-Id ] > [ Error-Message ] > * [ Failed-AVP ] > * [ Supported-Vendor-Id ] > * [ Auth-Application-Id ] > ***** * [ Inband-Security-Id ] > * [ Acct-Application-Id ] > * [ Vendor-Specific-Application-Id ] > [ Firmware-Revision ] > * [ AVP ] Those look good. > Section 5.6 > > Can someone help me here? Do we really want to complicate the state machine by > adding all the "If both ends support it, we do TLS now" states, or should we > just add a section 5.6.5 describing that a TLS handshake will begin when > both ends are in the open state, and all further messages will be sent via TLS? I think that that we just add section 5.6.5. > New Section 6.10 (bump the others) Got it, with modifications. Also bumped all references of 6.10 and on. > 6.10 Inband-Security-Id Should be: 6.10 Inband-Security-Id AVP > The Inband-Security-Id AVP (AVP Code TBD) is of type Unsigned32 and > is used in order to advertise support of the Security portion of the > application. > > Currently, the following values are supported, but there is ample room > to add new security Ids. > > NO_SECURITY 0 > This peer does not support any security model. This is the default > value, if the AVP is omitted. > > TLS 1 > This node supports TLS security, as defined by [TLS]. A small quibble - I think NO_SECURITY should be NO_TLS_Security. If IPsec is running, then there is security. So I propose: NO_TLS_SECURITY 0 This peer does not support the TLS security model. This is the default value, if the AVP is omitted. > Section 11.15 > > Delete the following lines: > > The following values are to be placed into the registry: > > Services Field Protocol AAA+D2T > TCP AAAS+D2T TLS over TCP AAA+D2S > SCTP AAAS+D2S TLS over SCTP > > Apendix B. NAPTR Example > > Delete all examples with AAAS. Result should look like: > > ;; order pref flags service regexp replacement > _diameters._sctp.ex.com. IN NAPTR 50 50 "s" "AAA+D2S" > "" _diameters._tcp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T" > "" _aaa._tcp.ex.com > > This indicates that the server supports SCTP and TCP, in that order. > If the client supports SCTP, SCTP will be used, targeted to a host > determined by an SRV lookup of _diameters._sctp.ex.com. That lookup > would return: > > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.ex.com IN SRV 0 2 > 5060 server2.ex.com Got it. Also added this to section 10.1 +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| ... Inband-Security-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | John From owner-aaa-wg@merit.edu Tue Apr 16 04:02:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26058 for ; Tue, 16 Apr 2002 04:02:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B705791271; Tue, 16 Apr 2002 04:02:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88F809127E; Tue, 16 Apr 2002 04:02:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8573C91271 for ; Tue, 16 Apr 2002 04:01:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 541C55DDE3; Tue, 16 Apr 2002 04:01:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7B2025DD92 for ; Tue, 16 Apr 2002 04:01:42 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G82jJ25430 for ; Tue, 16 Apr 2002 11:02:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Apr 2002 11:01:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 11:01:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Tue, 16 Apr 2002 11:01:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHkjD5VjeiO03toSd65MfF2X6BJVAAj3uYA From: To: Cc: , X-OriginalArrivalTime: 16 Apr 2002 08:01:40.0985 (UTC) FILETIME=[F1189690:01C1E51C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA26058 > Section 5.6 > > Can someone help me here? Do we really want to complicate the state machine by > adding all the "If both ends support it, we do TLS now" states, or should we > just add a section 5.6.5 describing that a TLS handshake will begin when > both ends are in the open state, and all further messages will be sent via TLS? Is something like this sufficient: For TLS usage, a TLS handshake will begin when both ends are in the open state. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state. John From owner-aaa-wg@merit.edu Tue Apr 16 05:36:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27879 for ; Tue, 16 Apr 2002 05:36:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68AB59122C; Tue, 16 Apr 2002 05:36:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CD039127E; Tue, 16 Apr 2002 05:36:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11E769122C for ; Tue, 16 Apr 2002 05:36:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEE785DDCC; Tue, 16 Apr 2002 05:36:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (unknown [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 585285DD92 for ; Tue, 16 Apr 2002 05:36:41 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3G9aal08292; Tue, 16 Apr 2002 04:36:36 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3G9aac10383; Tue, 16 Apr 2002 04:36:36 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id EAA24195; Tue, 16 Apr 2002 04:36:35 -0500 (CDT) Received: from ericberk107 (rcur181ip70.ericsson.se [147.214.181.70]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id EAA10019; Tue, 16 Apr 2002 04:36:34 -0500 (CDT) Message-ID: <00cd01c1e52a$32f63d30$46b5d693@ew.us.am.ericsson.se> From: "Kevin Purser" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAA@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Tue, 16 Apr 2002 11:36:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > The Inband-Security-Id AVP (AVP Code TBD) is of type Unsigned32 and > > is used in order to advertise support of the Security portion of the > > application. > > > > Currently, the following values are supported, but there is ample room > > to add new security Ids. > > > > NO_SECURITY 0 > > This peer does not support any security model. This is the default > > value, if the AVP is omitted. > > > > TLS 1 > > This node supports TLS security, as defined by [TLS]. > > A small quibble - I think NO_SECURITY should be NO_TLS_Security. If IPsec is > running, then there is security. I believe the idea with this AVP was to allow other potential transport layer security mechanisms to be used. Hence, NO_SECURITY. Kev From owner-aaa-wg@merit.edu Tue Apr 16 05:44:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27983 for ; Tue, 16 Apr 2002 05:44:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52B919127E; Tue, 16 Apr 2002 05:44:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 145749127F; Tue, 16 Apr 2002 05:44:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1A859127E for ; Tue, 16 Apr 2002 05:44:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACC785DE1D; Tue, 16 Apr 2002 05:44:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id E2C2F5DD92 for ; Tue, 16 Apr 2002 05:44:37 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G9jeJ14178 for ; Tue, 16 Apr 2002 12:45:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Apr 2002 12:44:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 16 Apr 2002 12:44:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Tue, 16 Apr 2002 12:44:35 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F29@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHlKjzeVxAKq6MUTKmiCUj02yd0TgAAOS6Q From: To: , X-OriginalArrivalTime: 16 Apr 2002 09:44:36.0388 (UTC) FILETIME=[51EC4E40:01C1E52B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA27983 Kevin, > I believe the idea with this AVP was to allow other potential > transport layer security mechanisms to be used. Hence, NO_SECURITY. Well, I'd like to say: NO_TRANSPORT_SECURITY or something. If IPsec is used, there is security, just not at the transport layer ... well, actually, I guess IPsec will still protect traffic at the transport layer as well. A better term needs to be found. John From owner-aaa-wg@merit.edu Tue Apr 16 05:49:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28015 for ; Tue, 16 Apr 2002 05:49:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FE7C9127F; Tue, 16 Apr 2002 05:48:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7C9A91280; Tue, 16 Apr 2002 05:48:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96F409127F for ; Tue, 16 Apr 2002 05:48:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74E2E5DE2E; Tue, 16 Apr 2002 05:48:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (unknown [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 1F6295DE1D for ; Tue, 16 Apr 2002 05:48:50 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3G9mJl10066; Tue, 16 Apr 2002 04:48:29 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3G9mJc12052; Tue, 16 Apr 2002 04:48:19 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id EAA25867; Tue, 16 Apr 2002 04:48:18 -0500 (CDT) Received: from ericberk107 (rcur181ip70.ericsson.se [147.214.181.70]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id EAA10149; Tue, 16 Apr 2002 04:48:17 -0500 (CDT) Message-ID: <00f501c1e52b$d5c18af0$46b5d693@ew.us.am.ericsson.se> From: "Kevin Purser" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F29@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Tue, 16 Apr 2002 11:48:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > I believe the idea with this AVP was to allow other potential > > transport layer security mechanisms to be used. Hence, NO_SECURITY. > > Well, I'd like to say: NO_TRANSPORT_SECURITY or something. If IPsec > is used, there is security, just not at the transport layer ... well, > actually, I guess IPsec will still protect traffic at the transport layer > as well. > > A better term needs to be found. Agreed. NO_TRANSPORT_SECURITY or NO_INBAND_SECURITY sound like a couple of good alternatives. Kev From owner-aaa-wg@merit.edu Tue Apr 16 08:28:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00674 for ; Tue, 16 Apr 2002 08:28:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39D2B91280; Tue, 16 Apr 2002 08:28:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0781791281; Tue, 16 Apr 2002 08:28:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6F9591280 for ; Tue, 16 Apr 2002 08:28:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A26065DE3F; Tue, 16 Apr 2002 08:28:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 177395DDCB for ; Tue, 16 Apr 2002 08:28:11 -0400 (EDT) Received: (qmail 21920 invoked by uid 500); 16 Apr 2002 12:28:10 -0000 Date: Tue, 16 Apr 2002 07:28:10 -0500 From: David Frascone To: john.loughney@nokia.com Cc: dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020416122810.GD14771@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAA@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAA@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Comments inline. On Tuesday, 16 Apr 2002, john.loughney@nokia.com wrote: > I agree with most of your changes, but I've kept section 3.2, but edited it > to be: > > 3.2 A client MUST discard any service fields that identify a resolution > service whose value is not "D2X", for values of X that indicate transport > protocols supported by the client. The NAPTR processing as described in > RFC 2915 will result in discovery of the most preferred transport protocol > of the server that is supported by the client, as well as an SRV record for the > server. > > The domain suffixes in the NAPTR replacement field SHOULD match the domain > of the original query. It is not necessary for the domain suffixes in the > NAPTR replacement field to match the domain of the original query. I like that. > > Section 5.3 > > > > [from first paragraph] > > state machine (see section 5.6). This message allows the discovery of > > a peer's identity and its capabilities (protocol version number, > > supported Diameter applications, security model, etc.) > ^^^^^^^^^^^^^^ > The avove is new only new text, correct? Correct. > > 6.10 Inband-Security-Id > > Should be: > > 6.10 Inband-Security-Id AVP Oops. Correct. > > > The Inband-Security-Id AVP (AVP Code TBD) is of type Unsigned32 and > > is used in order to advertise support of the Security portion of the > > application. > > > > Currently, the following values are supported, but there is ample room > > to add new security Ids. > > > > NO_SECURITY 0 > > This peer does not support any security model. This is the default > > value, if the AVP is omitted. > > > > TLS 1 > > This node supports TLS security, as defined by [TLS]. > > A small quibble - I think NO_SECURITY should be NO_TLS_Security. If IPsec is > running, then there is security. > > So I propose: > > NO_TLS_SECURITY 0 > This peer does not support the TLS security model. This is the > default value, if the AVP is omitted. Ok, then NO_INBAND_SECURITY. I think in the future someone might define SSLv2,3 or JOE_BOBS_UNHACKABLE_SECURITY and use it instead of TLS. > Also added this to section 10.1 > > +-----------------------------------------------+ > | Command-Code | > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > ... > Inband-Security-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Doh. Missed that one. Good Catch. > > John > -- David Frascone Diets are for those who are thick and tired of it. From owner-aaa-wg@merit.edu Tue Apr 16 08:33:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00890 for ; Tue, 16 Apr 2002 08:33:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D04491281; Tue, 16 Apr 2002 08:32:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30D1C91282; Tue, 16 Apr 2002 08:32:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E99691281 for ; Tue, 16 Apr 2002 08:32:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 041265DE01; Tue, 16 Apr 2002 08:32:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 57FC95DD9C for ; Tue, 16 Apr 2002 08:32:43 -0400 (EDT) Received: (qmail 22009 invoked by uid 500); 16 Apr 2002 12:32:43 -0000 Date: Tue, 16 Apr 2002 07:32:42 -0500 From: David Frascone To: john.loughney@nokia.com Cc: dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020416123242.GE14771@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I've been thinking about this a bit more. The TLS handshake will fail if the nodes have no prior knowledge of each other, or use a common CA, since site certificates must be validated. So, in that case, if a diameter peer is found by peer discovery, and both peers happen to do TLS, then by this paragraph they can never communicate, right? So, back to that old TLS certificates must be validated thingie: Can we state that TLS certificates MUST be validated, but MAY be self signed (you can also put in that self signed certificates are completely useless when it comes to determining identity, and are susceptable to man in the middle attacks)? -Dave On Tuesday, 16 Apr 2002, john.loughney@nokia.com wrote: > > > Section 5.6 > > > > Can someone help me here? Do we really want to complicate the state machine by > > adding all the "If both ends support it, we do TLS now" states, or should we > > just add a section 5.6.5 describing that a TLS handshake will begin when > > both ends are in the open state, and all further messages will be sent via TLS? > > Is something like this sufficient: > > For TLS usage, a TLS handshake will begin when both ends are in the open state. > If the TLS handshake is successful, all further messages will be sent via TLS. > If the handshake fails, both ends move to the closed state. > > John > -- David Frascone Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER From owner-aaa-wg@merit.edu Tue Apr 16 08:33:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00915 for ; Tue, 16 Apr 2002 08:33:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D252691285; Tue, 16 Apr 2002 08:33:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 792AC91284; Tue, 16 Apr 2002 08:33:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6128B91282 for ; Tue, 16 Apr 2002 08:33:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C3725DE01; Tue, 16 Apr 2002 08:33:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 8EFCA5DD9C for ; Tue, 16 Apr 2002 08:33:10 -0400 (EDT) Received: (qmail 22094 invoked by uid 500); 16 Apr 2002 12:33:10 -0000 Date: Tue, 16 Apr 2002 07:33:10 -0500 From: David Frascone To: john.loughney@nokia.com Cc: dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Message-ID: <20020416123309.GF14771@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Works for me. On Tuesday, 16 Apr 2002, john.loughney@nokia.com wrote: > > > Section 5.6 > > > > Can someone help me here? Do we really want to complicate the state machine by > > adding all the "If both ends support it, we do TLS now" states, or should we > > just add a section 5.6.5 describing that a TLS handshake will begin when > > both ends are in the open state, and all further messages will be sent via TLS? > > Is something like this sufficient: > > For TLS usage, a TLS handshake will begin when both ends are in the open state. > If the TLS handshake is successful, all further messages will be sent via TLS. > If the handshake fails, both ends move to the closed state. > > John > -- David Frascone After a number of decimal places, nobody gives a damn. From owner-aaa-wg@merit.edu Tue Apr 16 09:33:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03031 for ; Tue, 16 Apr 2002 09:33:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A9969122E; Tue, 16 Apr 2002 09:32:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EACAC91282; Tue, 16 Apr 2002 09:32:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7C279122E for ; Tue, 16 Apr 2002 09:32:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 982665DE44; Tue, 16 Apr 2002 09:32:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 0E1C35DE01 for ; Tue, 16 Apr 2002 09:32:48 -0400 (EDT) Received: (qmail 22729 invoked by uid 500); 16 Apr 2002 13:32:47 -0000 Date: Tue, 16 Apr 2002 08:32:47 -0500 From: David Frascone To: john.loughney@nokia.com, dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu Subject: [AAA-WG]: TLS with peer discovery broken (was Diameter should not require separate TLS port) Message-ID: <20020416133247.GL14771@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, dave@frascone.com, aboba@internaut.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> <20020416123242.GE14771@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020416123242.GE14771@newman.frascone.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Ok, I'm not sure that the below paragraphs are actually english, so I'm restating them, and changing the subject. First, let's take an example w/o TLS. A diameter server at aaa.somewhere.net tries to find a Diameter server for the realm frascone.com, and ends up with aaa.frascone.com, after checking for DNS SRV records. Since neither peer supports TLS (or only one supports TLS) they connect and communicate happily. But, let's suppose that they *both* have support for TLS. Since they have no prior knowledge of each other, and since there are no CA's defined *today*, they can not interoperate, since they can't validate the certificates. I think this is not acceptable. Security is now keeping us from interoperating. I think that if peers have no prior knowledge of each other, and both happen to support TLS, then a self signed certificate should be acceptable. I admit that there is no guarantee of identity here, but there wasn't any guarantee before, without the TLS. Or, as in my previous e-mails, they should be allowed to fall back to an insecure connection. (Remember, this is not for all secure connections, just for ones where the servers have no prior knowledge or shared CA with each other) Just my $.02 worth, Dave On Tuesday, 16 Apr 2002, David Frascone wrote: > I've been thinking about this a bit more. The TLS handshake will fail if > the nodes have no prior knowledge of each other, or use a common CA, since > site certificates must be validated. > > So, in that case, if a diameter peer is found by peer discovery, and both > peers happen to do TLS, then by this paragraph they can never communicate, > right? > > So, back to that old TLS certificates must be validated thingie: Can we state > that TLS certificates MUST be validated, but MAY be self signed (you can also > put in that self signed certificates are completely useless when it comes > to determining identity, and are susceptable to man in the middle attacks)? > > -Dave > > On Tuesday, 16 Apr 2002, john.loughney@nokia.com wrote: > > > > > Section 5.6 > > > > > > Can someone help me here? Do we really want to complicate the state machine by > > > adding all the "If both ends support it, we do TLS now" states, or should we > > > just add a section 5.6.5 describing that a TLS handshake will begin when > > > both ends are in the open state, and all further messages will be sent via TLS? > > > > Is something like this sufficient: > > > > For TLS usage, a TLS handshake will begin when both ends are in the open state. > > If the TLS handshake is successful, all further messages will be sent via TLS. > > If the handshake fails, both ends move to the closed state. > > > > John > > > > -- > David Frascone > > Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER > -- David Frascone Catatonic (n.) - Italian beverage most preferred by cats. From owner-aaa-wg@merit.edu Tue Apr 16 09:54:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04337 for ; Tue, 16 Apr 2002 09:54:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E78491282; Tue, 16 Apr 2002 09:53:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C27B91283; Tue, 16 Apr 2002 09:53:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B53391282 for ; Tue, 16 Apr 2002 09:53:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A0935DE46; Tue, 16 Apr 2002 09:53:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 664D95DE01 for ; Tue, 16 Apr 2002 09:53:54 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3GDrrb28704 for ; Tue, 16 Apr 2002 14:53:53 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 16 Apr 2002 14:48:25 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA29870; Tue, 16 Apr 2002 14:53:50 +0100 Message-ID: <3CBC2CF9.23FEF0A3@baltimore.ie> Date: Tue, 16 Apr 2002 14:54:01 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: TLS with peer discovery broken (was Diameter should not require separate TLS port) References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DAB@esebe004.NOE.Nokia.com> <20020416123242.GE14771@newman.frascone.com> <20020416133247.GL14771@newman.frascone.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, I don't like this approach. Presumably someone added/turned-on the TLS support for some reason, accepting self-signed things like this simply allows a DNS poisoning and spoofing attack to work straight away. Where's the use case for peer discovery and *in*-security? If there really is one, then I'd suggest allowing anonymous ciphersuites in that case rather than pretend certificates. If there is no such use case (as I believe) then we just have to accept that having reasonable security requires some co-ordination (in this case the TLS peers being able to validate one another's certificates). Finally, and somewhat tangentally (since its no basis on which to argue here), its entirely spurious to say there aren't CAs today - there are *plenty* of places to get real TLS certificates (with some policy backing them) today and there's also sufficient free technology available that'd allow anyone to establish their own free CA if they wanted. The fact is that this is one of the few times that I get to say that what's not deployed is Diameter, rather than TLS-capable PKI:-) Stephen. David Frascone wrote: > > Ok, I'm not sure that the below paragraphs are actually english, so I'm > restating them, and changing the subject. > > First, let's take an example w/o TLS. A diameter server at aaa.somewhere.net > tries to find a Diameter server for the realm frascone.com, and ends up with > aaa.frascone.com, after checking for DNS SRV records. Since neither peer > supports TLS (or only one supports TLS) they connect and communicate > happily. > > But, let's suppose that they *both* have support for TLS. Since they have > no prior knowledge of each other, and since there are no CA's defined *today*, > they can not interoperate, since they can't validate the certificates. I > think this is not acceptable. Security is now keeping us from interoperating. > > I think that if peers have no prior knowledge of each other, and both happen > to support TLS, then a self signed certificate should be acceptable. I admit > that there is no guarantee of identity here, but there wasn't any guarantee > before, without the TLS. Or, as in my previous e-mails, they should be > allowed to fall back to an insecure connection. (Remember, this is not for > all secure connections, just for ones where the servers have no prior knowledge > or shared CA with each other) > > Just my $.02 worth, > > Dave > > On Tuesday, 16 Apr 2002, David Frascone wrote: > > I've been thinking about this a bit more. The TLS handshake will fail if > > the nodes have no prior knowledge of each other, or use a common CA, since > > site certificates must be validated. > > > > So, in that case, if a diameter peer is found by peer discovery, and both > > peers happen to do TLS, then by this paragraph they can never communicate, > > right? > > > > So, back to that old TLS certificates must be validated thingie: Can we state > > that TLS certificates MUST be validated, but MAY be self signed (you can also > > put in that self signed certificates are completely useless when it comes > > to determining identity, and are susceptable to man in the middle attacks)? > > > > -Dave > > > > On Tuesday, 16 Apr 2002, john.loughney@nokia.com wrote: > > > > > > > Section 5.6 > > > > > > > > Can someone help me here? Do we really want to complicate the state machine by > > > > adding all the "If both ends support it, we do TLS now" states, or should we > > > > just add a section 5.6.5 describing that a TLS handshake will begin when > > > > both ends are in the open state, and all further messages will be sent via TLS? > > > > > > Is something like this sufficient: > > > > > > For TLS usage, a TLS handshake will begin when both ends are in the open state. > > > If the TLS handshake is successful, all further messages will be sent via TLS. > > > If the handshake fails, both ends move to the closed state. > > > > > > John > > > > > > > -- > > David Frascone > > > > Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER > > > > -- > David Frascone > > Catatonic (n.) - Italian beverage most preferred by cats. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Apr 16 10:02:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05059 for ; Tue, 16 Apr 2002 10:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84DE791283; Tue, 16 Apr 2002 10:02:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5095A91284; Tue, 16 Apr 2002 10:02:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AAC691283 for ; Tue, 16 Apr 2002 10:02:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 112A15DE46; Tue, 16 Apr 2002 10:02:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 81B025DE01 for ; Tue, 16 Apr 2002 10:02:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3GDHo312106; Tue, 16 Apr 2002 06:17:50 -0700 Date: Tue, 16 Apr 2002 06:17:50 -0700 (PDT) From: Bernard Aboba To: David Frascone Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter should not require separate TLS port) In-Reply-To: <20020416133247.GL14771@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > First, let's take an example w/o TLS. A diameter server at aaa.somewhere.net > tries to find a Diameter server for the realm frascone.com, and ends up with > aaa.frascone.com, after checking for DNS SRV records. Since neither peer > supports TLS (or only one supports TLS) they connect and communicate > happily. Presumably there is reason for somewhere.net to believe that as a result of letting david@frascone.com on the network, they will be paid for the usage. That indicates that business relationships exist along the "roaming relationship path". > But, let's suppose that they *both* have support for TLS. Since they have > no prior knowledge of each other, and since there are no CA's defined *today*, > they can not interoperate, since they can't validate the certificates. I > think this is not acceptable. Security is now keeping us from interoperating. So you're saying that the "business relationships" exist, but not the certificates corresponding to them. For example, frascone.com's certificate has not been signed by bigroamingconsortia.com with whom somewhere.net has a business relationship. And perhaps bigroamingconsortia.com's certificate has not been signed by one of somewhere.net's trusted roots. > I think that if peers have no prior knowledge of each other, and both happen > to support TLS, then a self signed certificate should be acceptable. I could see pre-configuring a Diameter agent with a set of "trusted peers" which might have self-signed certificates. As long as the certificates are cached, the risk will only exist on the first contact. For example, somewhere.net might create a business relationship with bigroamingconsortia.com and then cache its self-signed cert. Similarly, bigroamingconsortia.com might cache the self-signed cert of frascone.com after creating a business relationship with that organization. From owner-aaa-wg@merit.edu Tue Apr 16 10:21:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05897 for ; Tue, 16 Apr 2002 10:21:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8662391284; Tue, 16 Apr 2002 10:21:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5211491286; Tue, 16 Apr 2002 10:21:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31AE691284 for ; Tue, 16 Apr 2002 10:21:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11F6F5DE46; Tue, 16 Apr 2002 10:21:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 8FDED5DE01 for ; Tue, 16 Apr 2002 10:21:21 -0400 (EDT) Received: (qmail 23499 invoked by uid 500); 16 Apr 2002 14:21:21 -0000 Date: Tue, 16 Apr 2002 09:21:21 -0500 From: David Frascone To: Bernard Aboba Cc: David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter should not require separate TLS port) Message-ID: <20020416142120.GB22982@newman.frascone.com> Mail-Followup-To: Bernard Aboba , David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu References: <20020416133247.GL14771@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk A couple more rants inline :) On Tuesday, 16 Apr 2002, Bernard Aboba wrote: > So you're saying that the "business relationships" exist, but not the > certificates corresponding to them. For example, frascone.com's > certificate has not been signed by bigroamingconsortia.com with whom > somewhere.net has a business relationship. And perhaps > bigroamingconsortia.com's certificate has not been signed by one of > somewhere.net's trusted roots. > > > I think that if peers have no prior knowledge of each other, and both happen > > to support TLS, then a self signed certificate should be acceptable. > > I could see pre-configuring a Diameter agent with a set of "trusted > peers" which might have self-signed certificates. As long as the That whole pre-configuring thing goes completely against the "no prior knowledge" that I was talking about. Remember, this is functionality that existed *before* TLS handshaking. This is not something new that I'm trying to be a zealot about. If everyone thinks that it's ok to loose this functionality, fine. But, I really don't see why we spent so much time defining DNS SRV records and other forms of peer disovery, if they are useless without CAs or prior knowledge of the host. (And, with prior knowledge, peer discovery is not needed) > certificates are cached, the risk will only exist on the first > contact. For example, somewhere.net might create a business relationship > with bigroamingconsortia.com and then cache its self-signed cert. > > Similarly, bigroamingconsortia.com might cache the self-signed cert of > frascone.com after creating a business relationship with that > organization. > > > -- David Frascone Artist seeks Boss with vision impairment. From owner-aaa-wg@merit.edu Tue Apr 16 10:23:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06000 for ; Tue, 16 Apr 2002 10:23:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EBCF91286; Tue, 16 Apr 2002 10:23:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC91591287; Tue, 16 Apr 2002 10:23:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91C1A91286 for ; Tue, 16 Apr 2002 10:23:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 785605DE46; Tue, 16 Apr 2002 10:23:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id A986F5DE01 for ; Tue, 16 Apr 2002 10:23:32 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3GENWb29533 for ; Tue, 16 Apr 2002 15:23:32 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 16 Apr 2002 15:18:04 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA30422; Tue, 16 Apr 2002 15:23:29 +0100 Message-ID: <3CBC33EB.5A93F166@baltimore.ie> Date: Tue, 16 Apr 2002 15:23:39 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: Bernard Aboba , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter should not require separate TLS port) References: <20020416133247.GL14771@newman.frascone.com> <20020416142120.GB22982@newman.frascone.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, The prior knowledge is not of the host, but of the CA concerned, which can be a 1,000,000:1 difference! Stephen. David Frascone wrote: > > A couple more rants inline :) > > On Tuesday, 16 Apr 2002, Bernard Aboba wrote: > > So you're saying that the "business relationships" exist, but not the > > certificates corresponding to them. For example, frascone.com's > > certificate has not been signed by bigroamingconsortia.com with whom > > somewhere.net has a business relationship. And perhaps > > bigroamingconsortia.com's certificate has not been signed by one of > > somewhere.net's trusted roots. > > > > > I think that if peers have no prior knowledge of each other, and both happen > > > to support TLS, then a self signed certificate should be acceptable. > > > > I could see pre-configuring a Diameter agent with a set of "trusted > > peers" which might have self-signed certificates. As long as the > > That whole pre-configuring thing goes completely against the "no prior > knowledge" that I was talking about. > > Remember, this is functionality that existed *before* TLS handshaking. This > is not something new that I'm trying to be a zealot about. > > If everyone thinks that it's ok to loose this functionality, fine. But, > I really don't see why we spent so much time defining DNS SRV records and > other forms of peer disovery, if they are useless without CAs or prior > knowledge of the host. (And, with prior knowledge, peer discovery is not > needed) > > > certificates are cached, the risk will only exist on the first > > contact. For example, somewhere.net might create a business relationship > > with bigroamingconsortia.com and then cache its self-signed cert. > > > > Similarly, bigroamingconsortia.com might cache the self-signed cert of > > frascone.com after creating a business relationship with that > > organization. > > > > > > > > -- > David Frascone > > Artist seeks Boss with vision impairment. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Apr 16 10:41:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06599 for ; Tue, 16 Apr 2002 10:41:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 745AC91287; Tue, 16 Apr 2002 10:40:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A30591288; Tue, 16 Apr 2002 10:40:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1384C91287 for ; Tue, 16 Apr 2002 10:40:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D67C25DE4C; Tue, 16 Apr 2002 10:40:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 8C4745DE01 for ; Tue, 16 Apr 2002 10:40:50 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 07:40:48 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com'" , johanj@ipunplugged.com Cc: mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Date: Tue, 16 Apr 2002 07:40:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E554.B2ADC230" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E554.B2ADC230 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Except that Diameter workgroup is not a known entity. Perhaps Standards track instead? PatC - -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tuesday, April 16, 2002 12:12 AM To: johanj@ipunplugged.com Cc: mjones@bridgewatersystems.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications Hi Johan, > Actually on second thought we should probably even change it to > > ---------- > > - Application Identifier. An application is identified by a vendor > id and an application id. If the application is one defined by > the Diameter > workgroup the vendor id is 0. A route entry can have a different > destination based on the application identification avp of > the message. > This is one of Acct-Application-Id (for accounting > messages), Auth-Application-Id (for non-accounting messages) or > Vendor-Specific-Application-Id (for vendor specific messages). This > field MUST be used as a secondary key field > in routing table lookups. I think this is OK. John -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1UC LIULXOcDjuyI5NMSvKRtf5Jp =5tUq -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1E554.B2ADC230 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue #327: Message routing and vendor specific = applications

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Except that Diameter workgroup is not a known entity. = Perhaps
Standards track instead?

PatC

- -----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Tuesday, April 16, 2002 12:12 AM
To: johanj@ipunplugged.com
Cc: mjones@bridgewatersystems.com; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Issue #327: Message routing = and vendor
specific applications


Hi Johan,

> Actually on second thought we should probably = even change it to
>
> ----------
>
> - Application Identifier. An application is = identified by a vendor
> id and an application id. If the application is = one defined by
> the Diameter
> workgroup the vendor id is 0. A route entry can = have a different
> destination based on the application = identification avp of
> the message.
> This is one of Acct-Application-Id (for = accounting
> messages), Auth-Application-Id (for = non-accounting messages) or
> Vendor-Specific-Application-Id (for vendor = specific messages). This
>  field MUST be used as a secondary key = field
> in routing table lookups.

I think this is OK.

John

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1U= C
LIULXOcDjuyI5NMSvKRtf5Jp
=3D5tUq
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1E554.B2ADC230-- From owner-aaa-wg@merit.edu Tue Apr 16 10:47:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06861 for ; Tue, 16 Apr 2002 10:47:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8EF59122F; Tue, 16 Apr 2002 10:47:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F22E91231; Tue, 16 Apr 2002 10:47:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E1D99122F for ; Tue, 16 Apr 2002 10:47:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CC805DE50; Tue, 16 Apr 2002 10:47:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 7F7FA5DE01 for ; Tue, 16 Apr 2002 10:47:29 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3GEkmb10648; Tue, 16 Apr 2002 16:46:48 +0200 Message-ID: <3CBC3927.2090206@ipunplugged.com> Date: Tue, 16 Apr 2002 16:45:59 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: "'john.loughney@nokia.com'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific app lications References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Pat that Diameter workgroup is suboptimal, but it was all I could think of at the time. Would IETF be wildly misleading? j Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Except that Diameter workgroup is not a known entity. Perhaps > Standards track instead? > > PatC > > - -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com] > Sent: Tuesday, April 16, 2002 12:12 AM > To: johanj@ipunplugged.com > Cc: mjones@bridgewatersystems.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor > specific applications > > > Hi Johan, > > > Actually on second thought we should probably even change it to > > > > ---------- > > > > - Application Identifier. An application is identified by a vendor > > id and an application id. If the application is one defined by > > the Diameter > > workgroup the vendor id is 0. A route entry can have a different > > destination based on the application identification avp of > > the message. > > This is one of Acct-Application-Id (for accounting > > messages), Auth-Application-Id (for non-accounting messages) or > > Vendor-Specific-Application-Id (for vendor specific messages). This > > field MUST be used as a secondary key field > > in routing table lookups. > > I think this is OK. > > John > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com> > > iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1UC > LIULXOcDjuyI5NMSvKRtf5Jp > =5tUq > -----END PGP SIGNATURE----- > From owner-aaa-wg@merit.edu Tue Apr 16 10:49:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06954 for ; Tue, 16 Apr 2002 10:49:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FD5B91231; Tue, 16 Apr 2002 10:49:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51D6F91288; Tue, 16 Apr 2002 10:49:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EBA691231 for ; Tue, 16 Apr 2002 10:49:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2F9C5DE50; Tue, 16 Apr 2002 10:49:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 936795DE4C for ; Tue, 16 Apr 2002 10:49:34 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 07:49:34 -0700 Message-ID: From: "Pat R. Calhoun" To: "'Johan Johansson'" Cc: "'john.loughney@nokia.com'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Date: Tue, 16 Apr 2002 07:49:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E555.EB8B4B80" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E555.EB8B4B80 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "If the application is one defined by the Diameter workgroup the vendor id is 0." Could be replaced with "For all IETF standards track Diameter applications, the vendor id MUST be set to zero." PatC - -----Original Message----- From: Johan Johansson [mailto:johanj@ipunplugged.com] Sent: Tuesday, April 16, 2002 7:46 AM To: Pat R. Calhoun Cc: 'john.loughney@nokia.com'; mjones@bridgewatersystems.com; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific app lications I agree with Pat that Diameter workgroup is suboptimal, but it was all I could think of at the time. Would IETF be wildly misleading? j Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Except that Diameter workgroup is not a known entity. Perhaps > Standards track instead? > > PatC > > - -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com] > Sent: Tuesday, April 16, 2002 12:12 AM > To: johanj@ipunplugged.com > Cc: mjones@bridgewatersystems.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor > specific applications > > > Hi Johan, > > > Actually on second thought we should probably even change it to > > > > ---------- > > > > - Application Identifier. An application is identified by a > > vendor id and an application id. If the application is one > > defined by the Diameter workgroup the vendor id is 0. A route > > entry can have a different destination based on the application > > identification avp of the message. > > This is one of Acct-Application-Id (for accounting > > messages), Auth-Application-Id (for non-accounting messages) or > > Vendor-Specific-Application-Id (for vendor specific messages). > > This > > field MUST be used as a secondary key field > > in routing table lookups. > > I think this is OK. > > John > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < > http://www.pgp.com> > > iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1UC > LIULXOcDjuyI5NMSvKRtf5Jp > =5tUq > -----END PGP SIGNATURE----- > -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPLw5/DN1fXKoxmisEQJxCgCfba2VqYWIUtO5zUNGNM1v9m1hI+AAnAm3 yGGw5FJTWs6M+riiLPpykI1g =76Up -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1E555.EB8B4B80 Content-Type: text/html RE: [AAA-WG]: Issue #327: Message routing and vendor specific app lications

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"If the application is one defined by the Diameter workgroup the
vendor id is 0."

Could be replaced with

"For all IETF standards track Diameter applications, the vendor id
MUST be set to zero."

PatC

- -----Original Message-----
From: Johan Johansson [mailto:johanj@ipunplugged.com]
Sent: Tuesday, April 16, 2002 7:46 AM
To: Pat R. Calhoun
Cc: 'john.loughney@nokia.com'; mjones@bridgewatersystems.com;
aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor
specific app lications


I agree with Pat that Diameter workgroup is suboptimal, but it was
all I
could think of at the time. Would IETF be wildly misleading?

j

Pat R. Calhoun wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Except that Diameter workgroup is not a known entity. Perhaps
> Standards track instead?
>
> PatC
>
> - -----Original Message-----
> From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com]
> Sent: Tuesday, April 16, 2002 12:12 AM
> To: johanj@ipunplugged.com
> Cc: mjones@bridgewatersystems.com; aaa-wg@merit.edu
> Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor
> specific  applications
>
>
> Hi Johan,
>
> > Actually on second thought we should probably even change it to
> >
> > ----------
> >
> > - Application Identifier. An application is identified by a
> > vendor  id and an application id. If the application is one
> > defined by the  Diameter workgroup the vendor id is 0. A route
> > entry can have a  different destination based on the application
> > identification avp of the message.
> > This is one of Acct-Application-Id (for accounting
> > messages), Auth-Application-Id (for non-accounting messages) or
> > Vendor-Specific-Application-Id (for vendor specific messages).
> > This
> >  field MUST be used as a secondary key field
> > in routing table lookups.
>
> I think this is OK.
>
> John
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <
> http://www.pgp.com>
>
> iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1UC
> LIULXOcDjuyI5NMSvKRtf5Jp
> =5tUq
> -----END PGP SIGNATURE-----
>



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPLw5/DN1fXKoxmisEQJxCgCfba2VqYWIUtO5zUNGNM1v9m1hI+AAnAm3
yGGw5FJTWs6M+riiLPpykI1g
=76Up
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1E555.EB8B4B80-- From owner-aaa-wg@merit.edu Tue Apr 16 10:57:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07193 for ; Tue, 16 Apr 2002 10:57:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79D0091288; Tue, 16 Apr 2002 10:57:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4378E91289; Tue, 16 Apr 2002 10:57:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18E9091288 for ; Tue, 16 Apr 2002 10:57:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3A5B5DE51; Tue, 16 Apr 2002 10:57:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 428B45DE50 for ; Tue, 16 Apr 2002 10:57:12 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g3GE0Bf13511; Tue, 16 Apr 2002 16:00:11 +0200 Message-ID: <3CBC3B8E.6020101@ipunplugged.com> Date: Tue, 16 Apr 2002 16:56:14 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: "'john.loughney@nokia.com'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific app lications References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A minor detail, but I specifically avoided using the word MUST since it implies that it could be done any other way. There is nothing to set to 0. The application's vendor id *is* 0. j Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > "If the application is one defined by the Diameter workgroup the > vendor id is 0." > > Could be replaced with > > "For all IETF standards track Diameter applications, the vendor id > MUST be set to zero." > > PatC > > - -----Original Message----- > From: Johan Johansson [ mailto:johanj@ipunplugged.com] > Sent: Tuesday, April 16, 2002 7:46 AM > To: Pat R. Calhoun > Cc: 'john.loughney@nokia.com'; mjones@bridgewatersystems.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor > specific app lications > > > I agree with Pat that Diameter workgroup is suboptimal, but it was > all I > could think of at the time. Would IETF be wildly misleading? > > j > > Pat R. Calhoun wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Except that Diameter workgroup is not a known entity. Perhaps > > Standards track instead? > > > > PatC > > > > - -----Original Message----- > > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com] > > Sent: Tuesday, April 16, 2002 12:12 AM > > To: johanj@ipunplugged.com > > Cc: mjones@bridgewatersystems.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor > > specific applications > > > > > > Hi Johan, > > > > > Actually on second thought we should probably even change it to > > > > > > ---------- > > > > > > - Application Identifier. An application is identified by a > > > vendor id and an application id. If the application is one > > > defined by the Diameter workgroup the vendor id is 0. A route > > > entry can have a different destination based on the application > > > identification avp of the message. > > > This is one of Acct-Application-Id (for accounting > > > messages), Auth-Application-Id (for non-accounting messages) or > > > Vendor-Specific-Application-Id (for vendor specific messages). > > > This > > > field MUST be used as a secondary key field > > > in routing table lookups. > > > > I think this is OK. > > > > John > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use < > > http://www.pgp.com > > > > > iQA/AwUBPLw37zN1fXKoxmisEQJimwCgpz2GRu7NwswM1t+n5WxKeRbBXXcAn1UC > > LIULXOcDjuyI5NMSvKRtf5Jp > > =5tUq > > -----END PGP SIGNATURE----- > > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com> > > iQA/AwUBPLw5/DN1fXKoxmisEQJxCgCfba2VqYWIUtO5zUNGNM1v9m1hI+AAnAm3 > yGGw5FJTWs6M+riiLPpykI1g > =76Up > -----END PGP SIGNATURE----- > From owner-aaa-wg@merit.edu Tue Apr 16 11:18:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07775 for ; Tue, 16 Apr 2002 11:18:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEEE991230; Tue, 16 Apr 2002 11:18:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84FD791289; Tue, 16 Apr 2002 11:18:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86DC091230 for ; Tue, 16 Apr 2002 11:18:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 688ED5DE50; Tue, 16 Apr 2002 11:18:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E694E5DE01 for ; Tue, 16 Apr 2002 11:18:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3GEXk616344; Tue, 16 Apr 2002 07:33:46 -0700 Date: Tue, 16 Apr 2002 07:33:46 -0700 (PDT) From: Bernard Aboba To: David Frascone Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter should not require separate TLS port) In-Reply-To: <20020416142120.GB22982@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If everyone thinks that it's ok to loose this functionality, fine. But, > I really don't see why we spent so much time defining DNS SRV records and > other forms of peer disovery, if they are useless without CAs or prior > knowledge of the host. (And, with prior knowledge, peer discovery is not > needed) DNS SRV, NAPSTR, etc. can solve the problem where there is a prior relationship with a Diameter server within the realm, but help is needed to find the server. This kind of situation isn't very compatible with IPsec w/pre-shared keys, since if the name of the peer isn't known beforehand, the pre-shared key can't be known either. From owner-aaa-wg@merit.edu Tue Apr 16 13:29:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22919 for ; Tue, 16 Apr 2002 13:29:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 337FF9128F; Tue, 16 Apr 2002 13:28:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB44191290; Tue, 16 Apr 2002 13:28:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC6889128F for ; Tue, 16 Apr 2002 13:28:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 891D95DE8C; Tue, 16 Apr 2002 13:28:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 23D835DE88 for ; Tue, 16 Apr 2002 13:28:50 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3GHSni21036; Tue, 16 Apr 2002 12:28:49 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3GHSn902076; Tue, 16 Apr 2002 12:28:49 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA10663; Tue, 16 Apr 2002 12:28:48 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA16597; Tue, 16 Apr 2002 12:28:47 -0500 (CDT) Message-ID: <3CBC5E96.9C9F108B@ericsson.com> Date: Tue, 16 Apr 2002 10:25:42 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 References: <3CB70B03.57C07E3E@ericsson.com> <3CBA9F14.40909@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think Siva may have a point regarding co-located CoA and the 'R' bit in advertisements, see previous mail discussion. The question has also been brought up on the mip_wg list and I hope that we soon can get some clarifications regarding this issue. /Tony Johan Johansson wrote: > Tony, > > What has happened with regard to issue #326 is that nobody has explained > why it is *not* allowed in mobile ip, or maybe I have missed some > emails. As I said, I'd be extatic to say that the CoA should always be > used but I can not find any support for this in rfc 3220. > > j > > Tony Johansson wrote: > > >All, > > > >>From all of the discussion made regarding issue #305 and #326. I've come > >to the following conclusions: > > > >* Adopt issue #305 with removing the MIP-Foriegn-Agent-Host AVP, since > >the spec does not specify any real use for it and no real need for it > >have been concluded. > > > >* Reject issue #326, since no one have really stated that this is needed > >or even allowed in mobile ip. > > > >Any comments / objections to this? > > > >/Tony > > From owner-aaa-wg@merit.edu Tue Apr 16 14:05:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27388 for ; Tue, 16 Apr 2002 14:05:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2F9391232; Tue, 16 Apr 2002 14:04:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CDAD91291; Tue, 16 Apr 2002 14:04:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CC2C91232 for ; Tue, 16 Apr 2002 14:04:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E2C25DEA3; Tue, 16 Apr 2002 14:04:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CDBFD5DE88 for ; Tue, 16 Apr 2002 14:04:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3GHKc625427 for ; Tue, 16 Apr 2002 10:20:38 -0700 Date: Tue, 16 Apr 2002 10:20:38 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Last Call on draft-ietf-aaa-transport-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on the "Authentication, Authorization and Accounting (AAA) Transport Profile" document, before sending this on to the IESG for consideration as a Proposed Standard. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-07.txt Please post issues with this document to aaa-wg@merit.edu by May 1, 2002, using the issue format described on the AAA issues list at: http://www.drizzle.com/~aboba/AAA/issues.html Note that the intent is for this to be the last AAA WG last call on this document, so if you have not read it carefully lately, now is the time. From owner-aaa-wg@merit.edu Tue Apr 16 14:09:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27769 for ; Tue, 16 Apr 2002 14:09:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AA0E91291; Tue, 16 Apr 2002 14:09:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6432391293; Tue, 16 Apr 2002 14:09:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35B4391291 for ; Tue, 16 Apr 2002 14:09:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CEC05DEA3; Tue, 16 Apr 2002 14:09:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id DE3B65DE88 for ; Tue, 16 Apr 2002 14:09:13 -0400 (EDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 0EF30E00C08; Tue, 16 Apr 2002 11:09:11 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id LAA24878; Tue, 16 Apr 2002 11:10:15 -0700 (PDT) Date: Tue, 16 Apr 2002 11:10:13 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Johan Johansson Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 In-Reply-To: <3CBA9F14.40909@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, 15 Apr 2002, Johan Johansson wrote: > What has happened with regard to issue #326 is that nobody has explained > why it is *not* allowed in mobile ip, or maybe I have missed some > emails. As I said, I'd be extatic to say that the CoA should always be > used but I can not find any support for this in rfc 3220. I could not find anything in RFC3220 that says that the (multi-homed) FA MUST use the COA as the src address in forwarding request to the HA. From what I can recollect, I think the MN MUST forward the request to the src address in the advertisement, irrespective of the COA it chooses from the advertisement. It seems like the COA != src-of-UDP-request scenario (at the HA) can happen even when the MN is using a FA COA. Siva From owner-aaa-wg@merit.edu Tue Apr 16 14:32:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00336 for ; Tue, 16 Apr 2002 14:32:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0711891293; Tue, 16 Apr 2002 14:32:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB03B91234; Tue, 16 Apr 2002 14:32:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A5CC91294 for ; Tue, 16 Apr 2002 14:32:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D18935DDCF; Tue, 16 Apr 2002 14:32:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 4B3B85DDAB for ; Tue, 16 Apr 2002 14:32:22 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3GIWJl16133; Tue, 16 Apr 2002 13:32:19 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3GIWJ918606; Tue, 16 Apr 2002 13:32:19 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA16907; Tue, 16 Apr 2002 13:32:18 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA17719; Tue, 16 Apr 2002 13:32:17 -0500 (CDT) Message-ID: <3CBC6D79.2F19510C@ericsson.com> Date: Tue, 16 Apr 2002 11:29:13 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Siva, This is RFC3220 specific questions, so can you please bring it up on the mip_wg instead. It's much better if we can get all of this clarified on the list where the RFC3220 belong. I assume that all of us that do care about the Diameter MIPv4 appl also follows the mip_wg list regarding these issues. Regards, /Tony Sivasundar Ramamurthy wrote: > On Mon, 15 Apr 2002, Johan Johansson wrote: > > > What has happened with regard to issue #326 is that nobody has explained > > why it is *not* allowed in mobile ip, or maybe I have missed some > > emails. As I said, I'd be extatic to say that the CoA should always be > > used but I can not find any support for this in rfc 3220. > > I could not find anything in RFC3220 that says that the (multi-homed) > FA MUST use the COA as the src address in forwarding request to the > HA. From what I can recollect, I think the MN MUST forward the request > to the src address in the advertisement, irrespective of the COA it > chooses from the advertisement. > > It seems like the COA != src-of-UDP-request scenario (at the HA) can > happen even when the MN is using a FA COA. > > Siva From owner-aaa-wg@merit.edu Tue Apr 16 15:08:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05422 for ; Tue, 16 Apr 2002 15:08:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAE5F91237; Tue, 16 Apr 2002 15:08:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8F4891295; Tue, 16 Apr 2002 15:08:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A461691237 for ; Tue, 16 Apr 2002 15:08:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88CC55DDD8; Tue, 16 Apr 2002 15:08:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 58D4D5DDAB for ; Tue, 16 Apr 2002 15:08:43 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id E92C0C00A3E; Tue, 16 Apr 2002 12:08:42 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA28334; Tue, 16 Apr 2002 12:09:35 -0700 (PDT) Date: Tue, 16 Apr 2002 12:09:35 -0700 (PDT) From: Joe Lau Message-Id: <200204161909.MAA28334@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Solution to issue #326 and #305 In-Reply-To: Cc: johanj@ipunplugged.com, tony.johansson@ericsson.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > What has happened with regard to issue #326 is that nobody has explained > > why it is *not* allowed in mobile ip, or maybe I have missed some > > emails. As I said, I'd be extatic to say that the CoA should always be > > used but I can not find any support for this in rfc 3220. > > I could not find anything in RFC3220 that says that the (multi-homed) > FA MUST use the COA as the src address in forwarding request to the > HA. From what I can recollect, I think the MN MUST forward the request > to the src address in the advertisement, irrespective of the COA it > chooses from the advertisement. This is because the MN, while visiting on the foreign network, can not use ARP. Instead, it retrieves the link-layer address from the advertisment that the FA sends out on its mobility interface. The mobility interface may not be the FA's COA interface, which is usually the "best connected" interface. Joe Lau > It seems like the COA != src-of-UDP-request scenario (at the HA) can > happen even when the MN is using a FA COA. From owner-aaa-wg@merit.edu Wed Apr 17 03:27:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11784 for ; Wed, 17 Apr 2002 03:27:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D1399123E; Wed, 17 Apr 2002 03:27:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 013D091240; Wed, 17 Apr 2002 03:27:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B21BA9123E for ; Wed, 17 Apr 2002 03:27:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C3E95DF34; Wed, 17 Apr 2002 03:27:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id B5AE65DE60 for ; Wed, 17 Apr 2002 03:27:22 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H7SPJ15542 for ; Wed, 17 Apr 2002 10:28:26 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 10:27:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 10:27:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Wed, 17 Apr 2002 10:27:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F36@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHlFuWOga8uN4RsSMWS0iqYTOozdAAylWcw From: To: , X-OriginalArrivalTime: 17 Apr 2002 07:27:19.0888 (UTC) FILETIME=[4EFFE500:01C1E5E1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11784 Hi Miguel, > I haven't found any statement in the base regarding the > management of Result-Codes in vendor specific applications. I > assume that a vendor specific application can assign its own > result codes. Is my understanding correct? > > If so and if there is consensus in the list I am happy to > provide the (small) required changes. Please file an issue & suggest text. This is the best way to get concensus. Thanks, John From owner-aaa-wg@merit.edu Wed Apr 17 03:33:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11858 for ; Wed, 17 Apr 2002 03:33:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76DAB91240; Wed, 17 Apr 2002 03:33:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42B6B91241; Wed, 17 Apr 2002 03:33:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19FD591240 for ; Wed, 17 Apr 2002 03:33:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E33255DDA3; Wed, 17 Apr 2002 03:33:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2533A5DD92 for ; Wed, 17 Apr 2002 03:33:36 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H7XqF07905 for ; Wed, 17 Apr 2002 10:33:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 10:33:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 10:33:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E5E2.2D8BAD1F" Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Date: Wed, 17 Apr 2002 10:33:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F39@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Thread-Index: AcHlVfJaYNAk0y6XSLqVsAi5ueptCgAjC+PQ From: To: , Cc: , X-OriginalArrivalTime: 17 Apr 2002 07:33:33.0658 (UTC) FILETIME=[2DC8ABA0:01C1E5E2] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E5E2.2D8BAD1F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 "If the application is one defined by the Diameter workgroup the=20 vendor id is 0." =20 =20 Excellent - I'll add this. =20 John=20 ------_=_NextPart_001_01C1E5E2.2D8BAD1F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue #327: Message routing and vendor specific app = lications
Hi=20 Pat,
 
 "If = the=20 application is one defined by the Diameter workgroup the =
vendor id is 0."  
 
Excellent - I'll add this.
 
John 
------_=_NextPart_001_01C1E5E2.2D8BAD1F-- From owner-aaa-wg@merit.edu Wed Apr 17 03:38:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11914 for ; Wed, 17 Apr 2002 03:38:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8848D91244; Wed, 17 Apr 2002 03:38:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 520BF91241; Wed, 17 Apr 2002 03:38:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0ACF91242 for ; Wed, 17 Apr 2002 03:38:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DB415DD92; Wed, 17 Apr 2002 03:38:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 8D19A5DDA3 for ; Wed, 17 Apr 2002 03:38:44 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H7d0F12897 for ; Wed, 17 Apr 2002 10:39:00 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 10:38:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 10:38:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter shouldnot require separate TLS port) Date: Wed, 17 Apr 2002 10:38:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F3A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter shouldnot require separate TLS port) Thread-Index: AcHlWe0kerbhSxBkThuCmv3TNe4jAAAiFx3w From: To: , Cc: X-OriginalArrivalTime: 17 Apr 2002 07:38:42.0187 (UTC) FILETIME=[E5AE75B0:01C1E5E2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11914 Hi all, > DNS SRV, NAPSTR, etc. can solve the problem where there is a prior > relationship with a Diameter server within the realm, but > help is needed to find the server. > > This kind of situation isn't very compatible with IPsec > w/pre-shared keys, since if the name of the peer isn't known > beforehand, the pre-shared key can't be known either. It sounds, in summary, that there may not be addtional text needed. However, there may be future work needed on how to securely discover and securely establish sessions between unknown Diameter peers, with as little prior knowledge of anything as possible. Do I understand it correctly? John From owner-aaa-wg@merit.edu Wed Apr 17 03:44:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12021 for ; Wed, 17 Apr 2002 03:44:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C38F91241; Wed, 17 Apr 2002 03:43:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1CE91242; Wed, 17 Apr 2002 03:43:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B8EE91241 for ; Wed, 17 Apr 2002 03:43:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 157FF5DDA3; Wed, 17 Apr 2002 03:43:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 53B905DD92 for ; Wed, 17 Apr 2002 03:43:48 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H7i4F17661 for ; Wed, 17 Apr 2002 10:44:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 10:43:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 10:43:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Date: Wed, 17 Apr 2002 10:43:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F3C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHlQi7MQcdUg+JDQJ2ox/gSDazGDwAoVm1g From: To: Cc: , X-OriginalArrivalTime: 17 Apr 2002 07:43:47.0105 (UTC) FILETIME=[9B6D4110:01C1E5E3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA12021 Hi Dave, > Ok, then NO_INBAND_SECURITY. I think in the future someone > might define > SSLv2,3 or JOE_BOBS_UNHACKABLE_SECURITY and use it instead of TLS. I'll go with this. John From owner-aaa-wg@merit.edu Wed Apr 17 04:34:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12563 for ; Wed, 17 Apr 2002 04:34:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1E0A91242; Wed, 17 Apr 2002 04:33:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87E4691243; Wed, 17 Apr 2002 04:33:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6132291242 for ; Wed, 17 Apr 2002 04:33:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45CF45DDA3; Wed, 17 Apr 2002 04:33:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id A81D45DD92 for ; Wed, 17 Apr 2002 04:33:50 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3H8Xnb17712 for ; Wed, 17 Apr 2002 09:33:49 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 17 Apr 2002 09:28:21 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA09743; Wed, 17 Apr 2002 09:33:47 +0100 Message-ID: <3CBD3376.421D7C0F@baltimore.ie> Date: Wed, 17 Apr 2002 09:33:58 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter shouldnot require separate TLS port) References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F3A@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > > Hi all, > > > DNS SRV, NAPSTR, etc. can solve the problem where there is a prior > > relationship with a Diameter server within the realm, but > > help is needed to find the server. > > > > This kind of situation isn't very compatible with IPsec > > w/pre-shared keys, since if the name of the peer isn't known > > beforehand, the pre-shared key can't be known either. > > It sounds, in summary, that there may not be addtional text needed. > However, there may be future work needed on how to securely discover > and securely establish sessions between unknown Diameter peers, > with as little prior knowledge of anything as possible. > > Do I understand it correctly? Sounds right to me. And some of that work won't require protocols, but agreements (e.g. to use a certain set of CAs). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Apr 17 08:16:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15380 for ; Wed, 17 Apr 2002 08:16:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C987791247; Wed, 17 Apr 2002 08:15:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9561891248; Wed, 17 Apr 2002 08:15:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82FF491247 for ; Wed, 17 Apr 2002 08:15:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD5E85DDFA; Wed, 17 Apr 2002 08:15:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id E2B135DE54 for ; Wed, 17 Apr 2002 08:15:24 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3HCFKB07336; Wed, 17 Apr 2002 14:15:20 +0200 Message-ID: <3CBD6733.3070202@ipunplugged.com> Date: Wed, 17 Apr 2002 14:14:43 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #327: Message routing and vendor specific app lications References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F39@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Actually I think Pat's suggestion was to *replace* that which was in the originally suggested text with: "For all IETF standards track Diameter applications, the vendor id MUST be set to zero." while my favourite is to merge both suggestions to "For all IETF standards track Diameter applications, the vendor id is 0." The reasoning behind not using "MUST be set to" is that the application's identifier can not be set. It *is* identified by vendor id 0 and application id X and if the vendor id is non-0 you have identified another application. The entry in the routing table can be set, but to say that you MUST set it to the application you want to route seems to insult implementor's intelligence. j john.loughney@nokia.com wrote: > Hi Pat, > > > > "If the application is one defined by the Diameter workgroup the > vendor id is 0." > > > > Excellent - I'll add this. > > > > John > From owner-aaa-wg@merit.edu Wed Apr 17 08:27:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15597 for ; Wed, 17 Apr 2002 08:27:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52BC891223; Wed, 17 Apr 2002 08:27:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24CBC91248; Wed, 17 Apr 2002 08:27:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 124EA91223 for ; Wed, 17 Apr 2002 08:27:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDB455DE54; Wed, 17 Apr 2002 08:27:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 0BF715DDFA for ; Wed, 17 Apr 2002 08:27:28 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HCRhF27746 for ; Wed, 17 Apr 2002 15:27:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 15:27:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 15:27:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Date: Wed, 17 Apr 2002 15:27:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F5C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #327: Message routing and vendor specific app lications Thread-Index: AcHmCdAZCrPLJyG3S0i9/LMiyX+RNAAAQxlQ From: To: Cc: , , X-OriginalArrivalTime: 17 Apr 2002 12:27:26.0472 (UTC) FILETIME=[3BC29080:01C1E60B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15597 Hi Johan, > Actually I think Pat's suggestion was to *replace* that which > was in the originally suggested text with: Actually, I meant I will replace the text and add ... > "For all IETF standards track Diameter applications, the vendor id > MUST be set to zero." > > while my favourite is to merge both suggestions to > > "For all IETF standards track Diameter applications, the > vendor id is 0." Works for me, I will replace the existing text with your suggested text. John From owner-aaa-wg@merit.edu Wed Apr 17 08:54:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16094 for ; Wed, 17 Apr 2002 08:54:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E64A891248; Wed, 17 Apr 2002 08:54:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B41FB91249; Wed, 17 Apr 2002 08:54:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DC3291248 for ; Wed, 17 Apr 2002 08:54:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 781655DE44; Wed, 17 Apr 2002 08:54:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id C7F555DDFA for ; Wed, 17 Apr 2002 08:54:11 -0400 (EDT) Received: (qmail 4914 invoked by uid 500); 17 Apr 2002 12:54:11 -0000 Date: Wed, 17 Apr 2002 07:54:11 -0500 From: David Frascone To: Stephen Farrell Cc: john.loughney@nokia.com, aboba@internaut.com, dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: TLS with peer discovery broken (was Diameter shouldnot require separate TLS port) Message-ID: <20020417125411.GM22982@newman.frascone.com> Mail-Followup-To: Stephen Farrell , john.loughney@nokia.com, aboba@internaut.com, dave@frascone.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F3A@esebe004.NOE.Nokia.com> <3CBD3376.421D7C0F@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CBD3376.421D7C0F@baltimore.ie> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk You've got it. On Wednesday, 17 Apr 2002, Stephen Farrell wrote: > > > john.loughney@nokia.com wrote: > > > > Hi all, > > > > > DNS SRV, NAPSTR, etc. can solve the problem where there is a prior > > > relationship with a Diameter server within the realm, but > > > help is needed to find the server. > > > > > > This kind of situation isn't very compatible with IPsec > > > w/pre-shared keys, since if the name of the peer isn't known > > > beforehand, the pre-shared key can't be known either. > > > > It sounds, in summary, that there may not be addtional text needed. > > However, there may be future work needed on how to securely discover > > and securely establish sessions between unknown Diameter peers, > > with as little prior knowledge of anything as possible. > > > > Do I understand it correctly? > > Sounds right to me. And some of that work won't require protocols, > but agreements (e.g. to use a certain set of CAs). > -- David Frascone Press all the keys at once to continue... From owner-aaa-wg@merit.edu Wed Apr 17 10:32:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20549 for ; Wed, 17 Apr 2002 10:32:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A49F091272; Wed, 17 Apr 2002 10:32:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78A009129E; Wed, 17 Apr 2002 10:32:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93FB791272 for ; Wed, 17 Apr 2002 10:32:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5703C5DD92; Wed, 17 Apr 2002 10:32:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id D72C35DD8D for ; Wed, 17 Apr 2002 10:32:08 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3HEW73G026816 for ; Wed, 17 Apr 2002 16:32:07 +0200 (MEST) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 17 16:21:31 2002 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 16:21:31 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED213F@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Wed, 17 Apr 2002 16:21:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue: Result codes in vendor specific applications Submitter name: Miguel-Angel Pallares Submitter email address: miguel-angel.pallares-lopez@ece.ericsson.se Date first submitted: 17-04-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: H Section: 4.6, 7.1 Reason for change: currently there is a lack of definition about whether a vendor specific application can define its own Result-Codes. New commands defined by a vendor may have an associated semantic that is not covered by the existing result codes. Proposed change: In section 4.6: "... Result-Code 268 7.1 Unsigned32 | M | P | | V | N | ..." changes to "... Result-Code 268 7.1 Unsigned32 | M | P | | | N | ..." In section 7.1: After the paragraph that begins with: "The Result-Code data field contains an IANA-managed..." A new paragraph would read: "Any vendor wishing to implement a vendor-specific Diameter command specific commands MAY use privately managed result codes. If the Result-Code AVP sent in the response to a vendor-specific command contains a vendor-specific result code the 'V' bit MUST be set and the Vendor-Id as described in 4.2 MUST be present". > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 17, 2002 3:27 AM > To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Hi Miguel, > > > > I haven't found any statement in the base regarding the > > management of Result-Codes in vendor specific applications. I > > assume that a vendor specific application can assign its own > > result codes. Is my understanding correct? > > > > If so and if there is consensus in the list I am happy to > > provide the (small) required changes. > > Please file an issue & suggest text. This is the best way > to get concensus. > > Thanks, > John > From owner-aaa-wg@merit.edu Wed Apr 17 10:55:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21658 for ; Wed, 17 Apr 2002 10:55:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CE739129E; Wed, 17 Apr 2002 10:55:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E9ED9129F; Wed, 17 Apr 2002 10:55:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7929F9129E for ; Wed, 17 Apr 2002 10:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 546075DE56; Wed, 17 Apr 2002 10:55:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CE72B5DE58 for ; Wed, 17 Apr 2002 10:55:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3HEAuL29796 for ; Wed, 17 Apr 2002 07:10:56 -0700 Date: Wed, 17 Apr 2002 07:10:55 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION: draft-walker-aaa-key-distribution-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk To: IETF-Announce: ; Subject: I-D ACTION:draft-walker-aaa-key-distribution-00.txt From: Internet-Drafts@ietf.org Date: Wed, 17 Apr 2002 09:54:10 -0400 CC: aaa-wg@merit.edu Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA Key Distribution Author(s) : J. Walker, R. Housley, N. Cam-Winget Filename : draft-walker-aaa-key-distribution-00.txt Pages : 11 Date : 16-Apr-02 This memo describes problems with the current AAA NASREQ key distribution mechanisms, and proposes enhancements to the NASREQ key distribution model to address these problems. Please send comments on this document to the aaa-wg@merit.edu mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt From owner-aaa-wg@merit.edu Wed Apr 17 11:22:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22774 for ; Wed, 17 Apr 2002 11:22:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 705E09124E; Wed, 17 Apr 2002 11:22:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A5159124F; Wed, 17 Apr 2002 11:22:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5065D9124E for ; Wed, 17 Apr 2002 11:22:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DE225DE5D; Wed, 17 Apr 2002 11:22:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2EA895DE54 for ; Wed, 17 Apr 2002 11:22:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3HEbgF02313 for ; Wed, 17 Apr 2002 07:37:42 -0700 Date: Wed, 17 Apr 2002 07:37:42 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 335: CMS Security does not protect against replay Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 335: CMS Security does not protect against session-key replay Submitter: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: April 16, 2002 Reference: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Document: MIP, NASREQ, CMS Comment type: T Priority: S Section: Rationale/Explanation of issue: CMS wrapping of session keys does not explicitly protect the key distribution from replay. Thus, although the NAS itself can assume a CMS-wrapped key is genuine and issued from the AAA server, the NAS cannot determine that the AVP it receives has not been issued already for some prior session. Instead, the NAS must assume that the AAA server is playing by the rules and issuing only fresh keys, and that there is no man-in-the- middle replacing AVPs before or after they are unwrapped by a lower- layer security mechanism. Many session establishment handshakes do not define adequate key confirmation handshakes, so the NAS could end up sending new data encrypted under already-used keys and IVs before the problem can be detected, potentially compromising previously sent data. Relying on TLS or IPsec does not solve the problem, because the replay protection afforded by such low-level mechanisms is not adequately bound to the AVP to prevent a Trojan horse from substituting an old AVP for the new one without detection. Proposed change: What is needed to defeat this kind of attack is to require the AAA server to incorporate a challenge from the NAS (and/or the NAS client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a timestamp into the AVP is another option, but maintaining synchronized time in many of the environments served by an AAA server introduces its own problems.) From owner-aaa-wg@merit.edu Wed Apr 17 11:38:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23572 for ; Wed, 17 Apr 2002 11:38:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E74779124F; Wed, 17 Apr 2002 11:38:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B51539129F; Wed, 17 Apr 2002 11:38:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8660A9124F for ; Wed, 17 Apr 2002 11:38:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 650375DE54; Wed, 17 Apr 2002 11:38:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id C642C5DDD4 for ; Wed, 17 Apr 2002 11:38:36 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3HFcZb29293 for ; Wed, 17 Apr 2002 16:38:35 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 17 Apr 2002 16:33:07 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA17104; Wed, 17 Apr 2002 16:38:32 +0100 Message-ID: <3CBD9703.DABC5E87@baltimore.ie> Date: Wed, 17 Apr 2002 16:38:43 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As far as I can see, that proposed change doesn't impact on the CMS document. Is there a suggestion that replay protection should be done by CMS wrapping? I'd hope not, in which case this issue doesn't affect CMS (the document, it does affect how CMS is used). Is it true that replay protection is required for various AVPs? If so, a case could be made for a generic approach to replay protection and not just for session key AVPs. Stephen. Bernard Aboba wrote: > > Issue 335: CMS Security does not protect against session-key replay > Submitter: Jesse Walker > Submitter email address: jesse.walker@intel.com > Date first submitted: April 16, 2002 > Reference: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt > Document: MIP, NASREQ, CMS > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > > CMS wrapping of session keys does not explicitly protect the > key distribution from replay. > Thus, although the NAS itself can assume a CMS-wrapped key is genuine > and issued from the AAA server, the NAS cannot determine that the AVP > it receives has not been issued already for some prior session. > Instead, the NAS must assume that the AAA server is playing by the > rules and issuing only fresh keys, and that there is no man-in-the- > middle replacing AVPs before or after they are unwrapped by a lower- > layer security mechanism. Many session establishment handshakes do > not define adequate key confirmation handshakes, so the NAS could end > up sending new data encrypted under already-used keys and IVs before > the problem can be detected, potentially compromising previously sent > data. Relying on TLS or IPsec does not solve > the problem, because the replay protection afforded by such low-level > mechanisms is not adequately bound to the AVP to prevent a Trojan > horse from substituting an old AVP for the new one without detection. > > Proposed change: > > What is needed to defeat this kind of attack is to require the > AAA server to incorporate a challenge from the NAS (and/or the NAS > client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a > timestamp into the AVP is another option, but maintaining > synchronized time in many of the environments served by an AAA server > introduces its own problems.) -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Apr 17 12:58:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26950 for ; Wed, 17 Apr 2002 12:58:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D707691250; Wed, 17 Apr 2002 12:58:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6470391251; Wed, 17 Apr 2002 12:58:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FD6491250 for ; Wed, 17 Apr 2002 12:58:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 206225DDF4; Wed, 17 Apr 2002 12:58:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7E5435DD8D for ; Wed, 17 Apr 2002 12:58:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3HGDVh07522; Wed, 17 Apr 2002 09:13:31 -0700 Date: Wed, 17 Apr 2002 09:13:31 -0700 (PDT) From: Bernard Aboba To: Stephen Farrell Cc: aaa-wg@merit.edu, jesse.walker@intel.com Subject: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay In-Reply-To: <3CBD9703.DABC5E87@baltimore.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, 17 Apr 2002, Stephen Farrell wrote: > As far as I can see, that proposed change doesn't impact on the CMS > document. Is there a suggestion that replay protection should be > done by CMS wrapping? I'd hope not, in which case this issue doesn't > affect CMS (the document, it does affect how CMS is used). I think you are correct. This is not a CMS issue per se. I will remove the issue from the CMS list. However, it does seem to be an issue for Base, MIP and NASREQ and so I have added it to those lists. > Is it true that replay protection is required for various AVPs? If so, > a case could be made for a generic approach to replay protection and > not just for session key AVPs. I think a case can be made that replay protection is required for Diameter PDUs. I also think that a proxy should not be able to replace a CMS-protected object with another object that it got from a previous PDU, without being detected. So protection against "cut and paste" attacks seems like an important issue. > > Issue 335: CMS Security does not protect against session-key replay > > Submitter: Jesse Walker > > Submitter email address: jesse.walker@intel.com > > Date first submitted: April 16, 2002 > > Reference: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt > > Document: MIP, NASREQ, CMS > > Comment type: T > > Priority: S > > Section: > > Rationale/Explanation of issue: > > > > CMS wrapping of session keys does not explicitly protect the > > key distribution from replay. > > Thus, although the NAS itself can assume a CMS-wrapped key is genuine > > and issued from the AAA server, the NAS cannot determine that the AVP > > it receives has not been issued already for some prior session. > > Instead, the NAS must assume that the AAA server is playing by the > > rules and issuing only fresh keys, and that there is no man-in-the- > > middle replacing AVPs before or after they are unwrapped by a lower- > > layer security mechanism. Many session establishment handshakes do > > not define adequate key confirmation handshakes, so the NAS could end > > up sending new data encrypted under already-used keys and IVs before > > the problem can be detected, potentially compromising previously sent > > data. Relying on TLS or IPsec does not solve > > the problem, because the replay protection afforded by such low-level > > mechanisms is not adequately bound to the AVP to prevent a Trojan > > horse from substituting an old AVP for the new one without detection. > > > > Proposed change: > > > > What is needed to defeat this kind of attack is to require the > > AAA server to incorporate a challenge from the NAS (and/or the NAS > > client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a > > timestamp into the AVP is another option, but maintaining > > synchronized time in many of the environments served by an AAA server > > introduces its own problems.) From owner-aaa-wg@merit.edu Wed Apr 17 13:10:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27639 for ; Wed, 17 Apr 2002 13:10:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8A55291252; Wed, 17 Apr 2002 13:10:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A29F91253; Wed, 17 Apr 2002 13:10:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2354091252 for ; Wed, 17 Apr 2002 13:10:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 038865DDF4; Wed, 17 Apr 2002 13:10:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 304715DDBE for ; Wed, 17 Apr 2002 13:10:22 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3HHALb31748 for ; Wed, 17 Apr 2002 18:10:21 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 17 Apr 2002 18:04:53 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA18756; Wed, 17 Apr 2002 18:10:17 +0100 Message-ID: <3CBDAC84.1906BA93@baltimore.ie> Date: Wed, 17 Apr 2002 18:10:28 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, jesse.walker@intel.com Subject: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, > I think a case can be made that replay protection is required for Diameter > PDUs. Fair enough. So maybe some sort of "freshness" AVP perhaps with a time and nonce and rules (TBD) for replay detection that don't require, but do work nicely with, synchronized clocks. Some questions: Replay detection (I think) always requires a replay cache of some sort or else state-maintenance. For the former case, are there nodes that can't afford any such storage? For the latter, I assume we do need to allow some stateless interactions? Are there nodes that'd have a hard time generating random nonces? What about nodes with no real time clock, or with a high probability of a wildly inaccurate clock? > I also think that a proxy should not be able to replace a > CMS-protected object with another object that it got from a previous PDU, > without being detected. So protection against "cut and paste" attacks > seems like an important issue. Is that really a requirement? Perhaps not all cut&paste operations are actually attacks! My preference would be that we define freshness as a Diameter concept and then say for each message whether the freshness stuff has the "P" bit set or not (or some such). Maybe even say that if CMS is used, then the freshness AVP MUST be signed/encrpyted, but I don't want us to require CMS just to get fresh. Stephen. > > > > Issue 335: CMS Security does not protect against session-key replay > > > Submitter: Jesse Walker > > > Submitter email address: jesse.walker@intel.com > > > Date first submitted: April 16, 2002 > > > Reference: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt > > > Document: MIP, NASREQ, CMS > > > Comment type: T > > > Priority: S > > > Section: > > > Rationale/Explanation of issue: > > > > > > CMS wrapping of session keys does not explicitly protect the > > > key distribution from replay. > > > Thus, although the NAS itself can assume a CMS-wrapped key is genuine > > > and issued from the AAA server, the NAS cannot determine that the AVP > > > it receives has not been issued already for some prior session. > > > Instead, the NAS must assume that the AAA server is playing by the > > > rules and issuing only fresh keys, and that there is no man-in-the- > > > middle replacing AVPs before or after they are unwrapped by a lower- > > > layer security mechanism. Many session establishment handshakes do > > > not define adequate key confirmation handshakes, so the NAS could end > > > up sending new data encrypted under already-used keys and IVs before > > > the problem can be detected, potentially compromising previously sent > > > data. Relying on TLS or IPsec does not solve > > > the problem, because the replay protection afforded by such low-level > > > mechanisms is not adequately bound to the AVP to prevent a Trojan > > > horse from substituting an old AVP for the new one without detection. > > > > > > Proposed change: > > > > > > What is needed to defeat this kind of attack is to require the > > > AAA server to incorporate a challenge from the NAS (and/or the NAS > > > client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a > > > timestamp into the AVP is another option, but maintaining > > > synchronized time in many of the environments served by an AAA server > > > introduces its own problems.) -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Apr 17 13:20:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28044 for ; Wed, 17 Apr 2002 13:20:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAC5391254; Wed, 17 Apr 2002 13:20:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACA0E91256; Wed, 17 Apr 2002 13:20:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0E8791254 for ; Wed, 17 Apr 2002 13:20:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A33BE5DDF4; Wed, 17 Apr 2002 13:20:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0FC285DDBE for ; Wed, 17 Apr 2002 13:20:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3HGZq808804; Wed, 17 Apr 2002 09:35:52 -0700 Date: Wed, 17 Apr 2002 09:35:51 -0700 (PDT) From: Bernard Aboba To: Stephen Farrell Cc: aaa-wg@merit.edu, jesse.walker@intel.com Subject: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay In-Reply-To: <3CBDAC84.1906BA93@baltimore.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Bernard, > > > I think a case can be made that replay protection is required for Diameter > > PDUs. > > Fair enough. So maybe some sort of "freshness" AVP perhaps with a time and > nonce and rules (TBD) for replay detection that don't require, but do work > nicely with, synchronized clocks. Ironically, RADIUS already has some of these mechanisms, such as the Event-Timestamp AVP, and the Request-Authenticator. There has already been an issue raised as to whether this level of "liveness" is supported within Diameter. > Some questions: > > Replay detection (I think) always requires a replay cache of some sort or > else state-maintenance. For the former case, are there nodes that can't > afford any such storage? For the latter, I assume we do need to allow > some stateless interactions? Logically, the NAS is the entity with the least resources, so it would be the entity that might not be able to implement a replay cache. However, I think what is being proposed here is a NAS-generated challenge (perhaps in the Request) that would be incorporated in the CMS encapsulation, so I'm not clear that a cache would be required. > Are there nodes that'd have a hard time generating random nonces? What > about nodes with no real time clock, or with a high probability of a > wildly inaccurate clock? I have been told that there are NASes that boot with very little randomness (as little as 4 bits). However, I suspect that Diameter agents can be assumed to support cryptographic quality random number generation. > > I also think that a proxy should not be able to replace a > > CMS-protected object with another object that it got from a previous PDU, > > without being detected. So protection against "cut and paste" attacks > > seems like an important issue. > > Is that really a requirement? Perhaps not all cut&paste operations are > actually attacks! So you're saying that a Proxy might replace a CMS-object with another one, and have that be a valid operation? Can you give an example of a situation in which this might be acceptable? My brain just blew a fuse :) > My preference would be that we define freshness as a > Diameter concept and then say for each message whether the freshness > stuff has the "P" bit set or not (or some such). Maybe even say that > if CMS is used, then the freshness AVP MUST be signed/encrpyted, but > I don't want us to require CMS just to get fresh. I think that makes sense. From owner-aaa-wg@merit.edu Wed Apr 17 13:25:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28282 for ; Wed, 17 Apr 2002 13:25:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A834891256; Wed, 17 Apr 2002 13:25:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71F99912A0; Wed, 17 Apr 2002 13:25:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5990991256 for ; Wed, 17 Apr 2002 13:25:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39F585DE0F; Wed, 17 Apr 2002 13:25:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 6F6A05DDBE for ; Wed, 17 Apr 2002 13:25:39 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3HHPcb32114 for ; Wed, 17 Apr 2002 18:25:38 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 17 Apr 2002 18:20:10 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA19011; Wed, 17 Apr 2002 18:25:34 +0100 Message-ID: <3CBDB019.8C1BEDA0@baltimore.ie> Date: Wed, 17 Apr 2002 18:25:45 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, jesse.walker@intel.com Subject: blown fuse (was: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay) References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So you're saying that a Proxy might replace a CMS-object with another one, > and have that be a valid operation? Can you give an example of a situation > in which this might be acceptable? My brain just blew a fuse :) No idea if its a real requirement but at least in principle: Alice->Proxy: fresh1+stuff+CMS-Enc(Bob,AVPs) Proxy->Bob-host1: fresh2+stuff+more-stuff+CMS-Enc(Bob,AVPs) Proxy->Bob-host2: fresh3+stuff+even-more-stuff+CMS-Enc(Bob,AVPs) Could happen for some accounting reason maybe? Ignore me if its nonsense. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Apr 17 13:29:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28465 for ; Wed, 17 Apr 2002 13:29:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBFA2912A0; Wed, 17 Apr 2002 13:28:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A581D912A1; Wed, 17 Apr 2002 13:28:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76F8C912A0 for ; Wed, 17 Apr 2002 13:28:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E9CA5DE0F; Wed, 17 Apr 2002 13:28:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id BEF7D5DDBE for ; Wed, 17 Apr 2002 13:28:53 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3HHSrb32204 for ; Wed, 17 Apr 2002 18:28:53 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 17 Apr 2002 18:23:24 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA19049; Wed, 17 Apr 2002 18:28:50 +0100 Message-ID: <3CBDB0DD.44DEF30D@baltimore.ie> Date: Wed, 17 Apr 2002 18:29:01 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, jesse.walker@intel.com Subject: Re: [AAA-WG]: Issue 335: CMS Security does not protect against replay References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Replay detection (I think) always requires a replay cache of some sort or > > else state-maintenance. For the former case, are there nodes that can't > > afford any such storage? For the latter, I assume we do need to allow > > some stateless interactions? > > Logically, the NAS is the entity with the least resources, so it would be > the entity that might not be able to implement a replay > cache. However, I think what is being proposed here is a NAS-generated > challenge (perhaps in the Request) that would be incorporated in the CMS > encapsulation, so I'm not clear that a cache would be required. Ok, so we can use state-maintenance schemes sometimes. Are there times when we can't? > > Are there nodes that'd have a hard time generating random nonces? What > > about nodes with no real time clock, or with a high probability of a > > wildly inaccurate clock? > > I have been told that there are NASes that boot with very little > randomness (as little as 4 bits). However, I suspect that Diameter agents > can be assumed to support cryptographic quality random number generation. Ok, so we make that a MUST then I guess. What about the clocks - are there nodes with no clock or do they all have one? (I like the idea of being able to use the time when its available!) Stephen. > > > > I also think that a proxy should not be able to replace a > > > CMS-protected object with another object that it got from a previous PDU, > > > without being detected. So protection against "cut and paste" attacks > > > seems like an important issue. > > > > Is that really a requirement? Perhaps not all cut&paste operations are > > actually attacks! > > So you're saying that a Proxy might replace a CMS-object with another one, > and have that be a valid operation? Can you give an example of a situation > in which this might be acceptable? My brain just blew a fuse :) > > > My preference would be that we define freshness as a > > Diameter concept and then say for each message whether the freshness > > stuff has the "P" bit set or not (or some such). Maybe even say that > > if CMS is used, then the freshness AVP MUST be signed/encrpyted, but > > I don't want us to require CMS just to get fresh. > > I think that makes sense. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Apr 18 08:46:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03394 for ; Thu, 18 Apr 2002 08:46:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB3E3912B7; Thu, 18 Apr 2002 08:45:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BADD9912B8; Thu, 18 Apr 2002 08:45:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEDD9912B7 for ; Thu, 18 Apr 2002 08:45:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 859F65DDC6; Thu, 18 Apr 2002 08:45:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 178725DDAF for ; Thu, 18 Apr 2002 08:45:55 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 65F6D6A907; Thu, 18 Apr 2002 15:45:47 +0300 (EEST) Message-ID: <3CBEA3D4.4000405@kolumbus.fi> Date: Thu, 18 Apr 2002 13:45:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: David Frascone Cc: john.loughney@nokia.com, bglee@etri.re.kr, aaa-wg@merit.edu Subject: Re: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EE5@esebe004.NOE.Nokia.com> <20020415130616.GK11022@newman.frascone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone wrote: > I think that reporting and handling multiple errors is extremely difficult > to do. I think for debugging, this would be a great feature. But, as far > as full implementations go, it is not anything useful. > > It doesn't change the behavior of the protocol, just adds more work to handle > the multiple errors. > > So, I vote "no". Me too. Should make clear though that the Diameter nodes are to report the first error they encounter, irrespective of potential other errors in the message. Jari From owner-aaa-wg@merit.edu Thu Apr 18 09:03:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04231 for ; Thu, 18 Apr 2002 09:03:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0030912BA; Thu, 18 Apr 2002 09:03:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85831912BB; Thu, 18 Apr 2002 09:03:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D0F5912BA for ; Thu, 18 Apr 2002 09:03:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D9865DE76; Thu, 18 Apr 2002 09:03:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by segue.merit.edu (Postfix) with ESMTP id 7B8A55DE4C for ; Thu, 18 Apr 2002 09:03:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Result codes in vendor specific applications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Apr 2002 16:03:09 +0300 Message-ID: Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHmHLzsl9dA1n9iQoGjFoIP7v3IUgAu3YQg From: "Sami Vaarala" To: "Miguel-Angel Pallares-Lopez (ECE)" , , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04231 Hi, The 'V'-flag in the AVP indicates that the AVP *code* is vendor specific -- not the value. The change suggested introduces essentially a private AVP that happens to have the same AVP code as the IANA-assigned Result-Code. Alternative changes: 1. Add a vendor-specific flag (and vendor ID) into the Result-Code AVP. 2. Add a value for each result category indicating vendor specific extra information. I.e., a generic "protocol error" with vendor specific additional information available. Even though a Diameter node has a single vendor ID itself, it is free to use vendor specific stuff of other vendors. Thus, the result code should be accompanied with the vendor ID that specified the code. -Sami -----Original Message----- From: Miguel-Angel Pallares-Lopez (ECE) [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] Sent: 17 April 2002 17:21 To: 'john.loughney@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications Issue: Result codes in vendor specific applications Submitter name: Miguel-Angel Pallares Submitter email address: miguel-angel.pallares-lopez@ece.ericsson.se Date first submitted: 17-04-2002 Reference: Document: draft-base-10 Comment type: Technical Priority: H Section: 4.6, 7.1 Reason for change: currently there is a lack of definition about whether a vendor specific application can define its own Result-Codes. New commands defined by a vendor may have an associated semantic that is not covered by the existing result codes. Proposed change: In section 4.6: "... Result-Code 268 7.1 Unsigned32 | M | P | | V | N | ..." changes to "... Result-Code 268 7.1 Unsigned32 | M | P | | | N | ..." In section 7.1: After the paragraph that begins with: "The Result-Code data field contains an IANA-managed..." A new paragraph would read: "Any vendor wishing to implement a vendor-specific Diameter command specific commands MAY use privately managed result codes. If the Result-Code AVP sent in the response to a vendor-specific command contains a vendor-specific result code the 'V' bit MUST be set and the Vendor-Id as described in 4.2 MUST be present". > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 17, 2002 3:27 AM > To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Hi Miguel, > > > > I haven't found any statement in the base regarding the > > management of Result-Codes in vendor specific applications. I > > assume that a vendor specific application can assign its own > > result codes. Is my understanding correct? > > > > If so and if there is consensus in the list I am happy to > > provide the (small) required changes. > > Please file an issue & suggest text. This is the best way > to get concensus. > > Thanks, > John > From owner-aaa-wg@merit.edu Thu Apr 18 10:02:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06530 for ; Thu, 18 Apr 2002 10:02:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C82F6912BB; Thu, 18 Apr 2002 10:02:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DCE7912BC; Thu, 18 Apr 2002 10:02:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8755E912BB for ; Thu, 18 Apr 2002 10:02:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A9905DE11; Thu, 18 Apr 2002 10:02:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id EA32B5DDCE for ; Thu, 18 Apr 2002 10:02:17 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA15739 for ; Thu, 18 Apr 2002 10:02:54 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id KAA02152 for ; Thu, 18 Apr 2002 10:04:38 -0400 (EDT) From: "Mark Jones" To: Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Thu, 18 Apr 2002 10:04:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Sami that flipping the 'V' bit in the AVP header to get a vendor-specific result code is inappropriate since it blocks any vendor from defining an AVP with code 268. This may be a problem for vendors who have already used this code in their RADIUS vendor-specifc AVPs. I would prefer to find the vendor-specific result codes in one AVP regardless of vendor rather than have to hunt for the message result based on vendor/application. However, I'd rather we introduce a new Vendor-Specific-Result-Code AVP instead of changing the existing Result-Code AVP to be a grouped AVP. Regards, Mark From owner-aaa-wg@merit.edu Thu Apr 18 10:04:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06627 for ; Thu, 18 Apr 2002 10:04:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E3F1912BC; Thu, 18 Apr 2002 10:04:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE200912BD; Thu, 18 Apr 2002 10:04:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E809A912BC for ; Thu, 18 Apr 2002 10:04:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFA1E5DE51; Thu, 18 Apr 2002 10:04:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 3DACB5DE4C for ; Thu, 18 Apr 2002 10:04:46 -0400 (EDT) Received: (qmail 17745 invoked by uid 500); 18 Apr 2002 14:04:45 -0000 Date: Thu, 18 Apr 2002 09:04:45 -0500 From: David Frascone To: Mark Jones Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Result codes in vendor specific applications Message-ID: <20020418140445.GM6728@newman.frascone.com> Mail-Followup-To: Mark Jones , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree completely. On Thursday, 18 Apr 2002, Mark Jones wrote: > I agree with Sami that flipping the 'V' bit in the AVP header to get a > vendor-specific result code is inappropriate since it blocks any vendor from > defining an AVP with code 268. This may be a problem for vendors who have > already used this code in their RADIUS vendor-specifc AVPs. > > I would prefer to find the vendor-specific result codes in one AVP > regardless of vendor rather than have to hunt for the message result based > on vendor/application. However, I'd rather we introduce a new > Vendor-Specific-Result-Code AVP instead of changing the existing Result-Code > AVP to be a grouped AVP. > > Regards, > Mark > > -- David Frascone Insert inevitable trivial witticism of your choice. From owner-aaa-wg@merit.edu Fri Apr 19 00:19:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01663 for ; Fri, 19 Apr 2002 00:19:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0D1D91245; Fri, 19 Apr 2002 00:18:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B268291251; Fri, 19 Apr 2002 00:18:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C13F91245 for ; Fri, 19 Apr 2002 00:18:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B5885DEA4; Fri, 19 Apr 2002 00:18:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B5A075DE7C for ; Fri, 19 Apr 2002 00:18:55 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3J4JDF13437 for ; Fri, 19 Apr 2002 07:19:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 07:18:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 07:18:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Fri, 19 Apr 2002 07:18:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F77@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHm4bqvdQ9JfBWWQF+xA1QNNxbwEQAd4OtQ From: To: , X-OriginalArrivalTime: 19 Apr 2002 04:18:54.0432 (UTC) FILETIME=[513FB600:01C1E759] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA01663 Hi Mark, > I would prefer to find the vendor-specific result codes in one AVP > regardless of vendor rather than have to hunt for the message > result based > on vendor/application. However, I'd rather we introduce a new > Vendor-Specific-Result-Code AVP instead of changing the > existing Result-Code AVP to be a grouped AVP. That sounds reasonable - anyone want to provide text? John From owner-aaa-wg@merit.edu Fri Apr 19 00:37:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02046 for ; Fri, 19 Apr 2002 00:37:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7608991255; Fri, 19 Apr 2002 00:36:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DC5D91259; Fri, 19 Apr 2002 00:36:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2352A91255 for ; Fri, 19 Apr 2002 00:36:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0322F5DE6E; Fri, 19 Apr 2002 00:36:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 4ACF35DDD3 for ; Fri, 19 Apr 2002 00:36:48 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3J4b5F18482 for ; Fri, 19 Apr 2002 07:37:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 07:36:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 07:36:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Date: Fri, 19 Apr 2002 07:36:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F7A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Thread-Index: AcHm1v6tpKrEyTUJTGSIXCTlFHE95QAhKi6Q From: To: , Cc: , X-OriginalArrivalTime: 19 Apr 2002 04:36:47.0158 (UTC) FILETIME=[D0A4B560:01C1E75B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA02046 Hi Jari, > Me too. Should make clear though that the Diameter nodes are > to report the > first error they encounter, irrespective of potential other > errors in the message. I don't think that this is important, actually. Depending upon how messages are processed (which is implementation dependent) then different implementations may see different first errors. John From owner-aaa-wg@merit.edu Fri Apr 19 01:32:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02622 for ; Fri, 19 Apr 2002 01:32:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 14BCE91259; Fri, 19 Apr 2002 01:31:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAE9D9125A; Fri, 19 Apr 2002 01:31:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A902891259 for ; Fri, 19 Apr 2002 01:31:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87AFB5DE76; Fri, 19 Apr 2002 01:31:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 4E7F05DE18 for ; Fri, 19 Apr 2002 01:31:55 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5FFEA6A905; Fri, 19 Apr 2002 08:31:46 +0300 (EEST) Message-ID: <3CBFABE8.6000306@kolumbus.fi> Date: Fri, 19 Apr 2002 08:32:24 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: dave@frascone.com, bglee@etri.re.kr, aaa-wg@merit.edu Subject: Re: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F7A@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Jari, > > >>Me too. Should make clear though that the Diameter nodes are >>to report the >>first error they encounter, irrespective of potential other >>errors in the message. >> > > I don't think that this is important, actually. Depending upon > how messages are processed (which is implementation dependent) then > different implementations may see different first errors. Yes, I agree. But what I really meant was that the diameter nodes should report the first error THEY encounter (could be different by different implementations). I'm not sure we explicitly state this anywhere at the moment. Hmm... checking... how about changing the last paragraph of 7 from The Result-Code AVP contains additional errors conditions, and defines the expected behavior of each. to The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order). The specific errors that can be described by this AVP are described in the following section. Jari From owner-aaa-wg@merit.edu Fri Apr 19 04:43:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13606 for ; Fri, 19 Apr 2002 04:43:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82CFB9125C; Fri, 19 Apr 2002 04:43:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54BB49128C; Fri, 19 Apr 2002 04:43:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13B0D9125C for ; Fri, 19 Apr 2002 04:43:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE33B5DEBC; Fri, 19 Apr 2002 04:43:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by segue.merit.edu (Postfix) with ESMTP id 59CEF5DD9E for ; Fri, 19 Apr 2002 04:43:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Result codes in vendor specific applications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Apr 2002 11:42:55 +0300 Message-ID: Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHm4bVSi57R8zz1T7KOeHnL7L+JOAAm/dGQ From: "Sami Vaarala" To: "Mark Jones" , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA13606 Mark, Would we then have a Result-Code that indicates a vendor-specific success/error code, which is then contained in the Vendor-Specific-Result-Code AVP? Does the receiver benefit from partial understanding ("it is an error, but it is vendor specific") provided by the Result-Code? Or would we simply have either Result-Code or Vendor-Specific-Result-Code? -Sami -----Original Message----- From: Mark Jones [mailto:mjones@bridgewatersystems.com] Sent: 18 April 2002 17:05 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications I agree with Sami that flipping the 'V' bit in the AVP header to get a vendor-specific result code is inappropriate since it blocks any vendor from defining an AVP with code 268. This may be a problem for vendors who have already used this code in their RADIUS vendor-specifc AVPs. I would prefer to find the vendor-specific result codes in one AVP regardless of vendor rather than have to hunt for the message result based on vendor/application. However, I'd rather we introduce a new Vendor-Specific-Result-Code AVP instead of changing the existing Result-Code AVP to be a grouped AVP. Regards, Mark From owner-aaa-wg@merit.edu Fri Apr 19 06:16:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15173 for ; Fri, 19 Apr 2002 06:16:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1E1A9128C; Fri, 19 Apr 2002 06:15:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 605DB91290; Fri, 19 Apr 2002 06:15:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30BAD9128C for ; Fri, 19 Apr 2002 06:15:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 791235DEBC; Fri, 19 Apr 2002 06:15:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id B0F015DEBB for ; Fri, 19 Apr 2002 06:15:19 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3JAFIs7022879 for ; Fri, 19 Apr 2002 12:15:18 +0200 (MEST) Received: FROM esealnt744.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 12:15:10 2002 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 12:15:10 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED216B@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Fri, 19 Apr 2002 12:15:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The proposed solution is fine with me. My opinion is that we should have only one result code in a message. I leave for your consideration whether we should change in 7.1 "All Diameter answer messages MUST include one Result-Code AVP" to "All Diameter answer messages MUST include either one Result-Code AVP or one Vendor-Specific-Result-Code AVP." I think this would be useful. Proposal of addition of a new subchapter inside chapter 7 (7.2 ?). 7.x Vendor-Specific-Result-Code AVP The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type Unsigned32 and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. All Diameter vendor-specific answer messages MUST include either one Vendor-Specific-Result-Code AVP or one Result-Code AVP. It is recommended that vendor-specific result codes follow the same conventions given for the Result-Code AVP regarding the different types of result codes and the handling of errors (for non 2xxx values). In chapter 4.6: After: ... Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | Application-Id | | | | | | Add: Vendor-Specific- TBD 7.x Unsigned32 | M | P | | V | N | Result-Code | | | | | | Best regards, Miguel > -----Original Message----- > From: Sami Vaarala [mailto:sami.vaarala@netseal.com] > Sent: Friday, April 19, 2002 4:43 AM > To: Mark Jones; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Mark, > > Would we then have a Result-Code that indicates a vendor-specific > success/error code, which is then contained in the > Vendor-Specific-Result-Code AVP? > > Does the receiver benefit from partial understanding ("it is an > error, but it is vendor specific") provided by the Result-Code? > > Or would we simply have either Result-Code or > Vendor-Specific-Result-Code? > > -Sami > > -----Original Message----- > From: Mark Jones [mailto:mjones@bridgewatersystems.com] > Sent: 18 April 2002 17:05 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > I agree with Sami that flipping the 'V' bit in the AVP header to get a > vendor-specific result code is inappropriate since it blocks > any vendor > from > defining an AVP with code 268. This may be a problem for vendors who > have > already used this code in their RADIUS vendor-specifc AVPs. > > I would prefer to find the vendor-specific result codes in one AVP > regardless of vendor rather than have to hunt for the message result > based > on vendor/application. However, I'd rather we introduce a new > Vendor-Specific-Result-Code AVP instead of changing the existing > Result-Code > AVP to be a grouped AVP. > > Regards, > Mark > > From owner-aaa-wg@merit.edu Fri Apr 19 07:35:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16396 for ; Fri, 19 Apr 2002 07:35:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26E8491292; Fri, 19 Apr 2002 07:35:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2841912A8; Fri, 19 Apr 2002 07:35:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C030091292 for ; Fri, 19 Apr 2002 07:35:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E7265DEBC; Fri, 19 Apr 2002 07:35:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id C45A15DEB6 for ; Fri, 19 Apr 2002 07:35:06 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 20:34:57 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A94616F@cms3.etri.re.kr> From: bglee@etri.re.kr To: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: Re: [AAA-WG]: What is Result Code Value ? In Multi-Failed AVP Cas e. Date: Fri, 19 Apr 2002 20:34:49 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E796.36E962A0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E796.36E962A0 Content-Type: text/plain; charset="euc-kr" Hi, Jari I agree with you. This Issue mean...The Failed-AVP AVP (AVP Code 279) is of type Grouped, so One answer message has just only one Result Code Avp and the Avp has also only one error cause value. In Failed Avp, all of the errored Avps may be encoded. so, Example) Failed-Avp Avp in ACA Message(From Failed ACR Message) +-------+-------+-------+-------+ 0 | AVP Header | Head(Failed-AVP AVP) +-------+-------+-------+-------+ 8 | Errored Origin-Host Avp | +-------+-------+-------+ 16 | Errored User-Name Avp | +-------+-------+------+ Body(Failed-AVP AVP) 24|Errored Record Number Avp| +-------+-------+-------+ 32 | Errored Record Type Avp | +-------+-------+-------+-------+ Errored Origin-Host Avp(Code : Diameter Invalid Avp Bit : 3009) Errored User-Name Avp(Code : Diameter Invalid Hdr Bit : 3007) Errored Record Number Avp(Code : Diameter Invalid Avp Value : 5004) Errored Record Type Avp(Code : Diameter Invalid Avp Value : 5004) In that case Result Code Value has just only one cause, i think. so, 1. It is difficult to match(the error code value, Failed-AVP AVP) 2. multiple error curred, but only one (which one ?------> first one is OK ! ) 3. Failed-AVP AVP is type Grouped.(I'm not sure why this is the grouped type.) I think for debugging, Error processing of received a Failed-AVP AVP is an implementation dependent case. But the answer message should include multiple error codes in Failed-AVP AVP i think. I recommend.. AVP Format ::= < AVP Header: 279 > 1* { {Result-Code or Result-Code AVP}/*Following AVP's Error Code Value included*/ {AVP} } /BGLee john.loughney@nokia.com wrote: > Hi Jari, > > >>Me too. Should make clear though that the Diameter nodes are >>to report the >>first error they encounter, irrespective of potential other >>errors in the message. >> > > I don't think that this is important, actually. Depending upon > how messages are processed (which is implementation dependent) then > different implementations may see different first errors. Yes, I agree. But what I really meant was that the diameter nodes should report the first error THEY encounter (could be different by different implementations). I'm not sure we explicitly state this anywhere at the moment. Hmm... checking... how about changing the last paragraph of 7 from The Result-Code AVP contains additional errors conditions, and defines the expected behavior of each. to The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order). The specific errors that can be described by this AVP are described in the following section. Jari ------_=_NextPart_001_01C1E796.36E962A0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: What is Result Code Value ? In Multi-Failed AVP = Case.

Hi, Jari
I agree with you.

This Issue mean...The Failed-AVP AVP (AVP Code 279) = is of type Grouped, so
One answer message has just only one Result Code Avp = and the Avp has also only one error cause value.
In Failed Avp, all of the errored Avps may be = encoded.
so,

Example) Failed-Avp Avp in ACA Message(From Failed = ACR Message)

       = +-------+-------+-------+-------+
    0 = |        AVP = Header           =    |   Head(Failed-AVP AVP)
       = +-------+-------+-------+-------+
    8 | Errored Origin-Host = Avp   |
      = +-------+-------+-------+
  16 | Errored User-Name Avp    = |
       = +-------+-------+------+    Body(Failed-AVP AVP)
   24|Errored Record Number Avp|
       = +-------+-------+-------+
  32 | Errored Record Type Avp   = |
       = +-------+-------+-------+-------+

Errored Origin-Host Avp(Code : Diameter Invalid Avp = Bit : 3009)
Errored User-Name Avp(Code : Diameter Invalid Hdr = Bit : 3007)
Errored Record Number Avp(Code : Diameter Invalid = Avp Value : 5004)
Errored Record Type Avp(Code : Diameter Invalid Avp = Value : 5004)

In that case Result Code Value has just only one = cause, i think.
 so,
 1. It is difficult to match(the error code = value,  Failed-AVP AVP)
 2. multiple error curred, but only one (which = one ?------> first one is OK ! )
 3. Failed-AVP AVP is type Grouped.(I'm not = sure why this is the grouped type.)    

I think for debugging,

Error processing of received a Failed-AVP AVP is an = implementation dependent case.
But the answer message should include multiple error = codes in Failed-AVP AVP i think.

I recommend..

 AVP Format
  <Failed-AVP> ::=3D < AVP Header: 279 = >
       1* {
          &nb= sp;  {Result-Code or Result-Code AVP}/*Following AVP's Error Code = Value included*/
          &nb= sp;  {AVP}
          &nb= sp; }
/BGLee




john.loughney@nokia.com wrote:
> Hi Jari,
>
>
>>Me too. Should make clear though that the = Diameter nodes are
>>to report the
>>first error they encounter, irrespective of = potential other
>>errors in the message.
>>
>
> I don't think that this is important, = actually.  Depending upon
> how messages are processed (which is = implementation dependent) then
> different implementations may see different = first errors.

Yes, I agree. But what I really meant was that the = diameter
nodes should report the first error THEY encounter = (could
be different by different implementations). I'm not = sure we
explicitly state this anywhere at the moment. Hmm... = checking...
how about changing the last paragraph of 7 = from
    The Result-Code AVP contains = additional errors conditions, and
    defines the expected behavior of = each.
to
    The Result-Code AVP describes the = error that the Diameter node
    encountered in its processing. In = case there are multiple errors,
    the Diameter node MUST report = only the first error it encountered
    (detected possibly in some = implementation dependent order). The
    specific errors that can be = described by this AVP are described in
    the following section.
Jari

------_=_NextPart_001_01C1E796.36E962A0-- From owner-aaa-wg@merit.edu Fri Apr 19 11:49:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24569 for ; Fri, 19 Apr 2002 11:49:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65DE7912CC; Fri, 19 Apr 2002 11:48:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 315A4912CF; Fri, 19 Apr 2002 11:48:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21620912CC for ; Fri, 19 Apr 2002 11:48:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 087755DF6D; Fri, 19 Apr 2002 11:48:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id A928D5DEA6 for ; Fri, 19 Apr 2002 11:48:48 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA07792; Fri, 19 Apr 2002 11:38:31 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id LAA19854; Fri, 19 Apr 2002 11:50:59 -0400 (EDT) From: "Mark Jones" To: "Sami Vaarala" , Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Fri, 19 Apr 2002 11:50:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sami, > Would we then have a Result-Code that indicates a vendor-specific > success/error code, which is then contained in the > Vendor-Specific-Result-Code AVP? > No, I'd prefer a single result code per message. > Does the receiver benefit from partial understanding ("it is an > error, but it is vendor specific") provided by the Result-Code? > I'm not sure that a receiver could act upon the partial understanding other than by just logging the result code(s). For an administrator to be able to debug the problem, the receiver would still have to log both Result-Code and the Vendor-Specific-Result-Code. If we decide the Result-Code AVP is required in addition to the Vendor-Specific-Result-Code, it also leaves developers with the question "Which generic Result-Code is most appropriate for my vendor-specifc problem?". This mapping may not always be obvious and so it will probably not be done consistently (especially across different vendors). Regards, Mark From owner-aaa-wg@merit.edu Fri Apr 19 12:09:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26054 for ; Fri, 19 Apr 2002 12:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63C1F912D8; Fri, 19 Apr 2002 12:08:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 396B1912DB; Fri, 19 Apr 2002 12:08:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AE42912D8 for ; Fri, 19 Apr 2002 12:08:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CBE65DFA6; Fri, 19 Apr 2002 12:08:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id E22715DFA0 for ; Fri, 19 Apr 2002 12:08:42 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA07945; Fri, 19 Apr 2002 11:58:36 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id MAA21850; Fri, 19 Apr 2002 12:11:03 -0400 (EDT) From: "Mark Jones" To: , Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Fri, 19 Apr 2002 12:11:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <577066326047D41180AC00508B955DDA05ED216B@eestqnt104> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel, To avoid result code collisions between vendors, I think the new AVP needs to include the Vendor-Id. Vendor-Specific-Result ::== < AVP Header: tbd > { Vendor-Id } { Vendor-Specific-Result-Code } where: Vendor-Id: Datatype: Unsigned32; AVP code: 266 Vendor-Specific-Result-Code: Datatype: Unsigned32; AVP code: Alternatively, IANA gets another AVP to police but this doesn't seem the right approach for an AVP that is only used in vendor-specific applications. Regards, Mark From owner-aaa-wg@merit.edu Fri Apr 19 14:41:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16508 for ; Fri, 19 Apr 2002 14:41:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B34C091203; Fri, 19 Apr 2002 14:40:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B71E912D9; Fri, 19 Apr 2002 14:40:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 936E291203 for ; Fri, 19 Apr 2002 14:40:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 672E25DF2A; Fri, 19 Apr 2002 14:40:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 528D05DDAD for ; Fri, 19 Apr 2002 14:40:48 -0400 (EDT) Received: from phoenix (natd.interlinknetworks.com [198.108.5.4]) by aaa.interlinknetworks.com (Postfix) with SMTP id 186446C; Fri, 19 Apr 2002 14:40:48 -0400 (EDT) From: "Bob Kopacz" To: "Johan Johansson" Cc: "Tony Johansson" , Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Fri, 19 Apr 2002 14:39:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3CBA9E63.3070200@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, > From: Johan Johansson [johanj@ipunplugged.com] > Sent: Monday, April 15, 2002 5:33 AM > To: Bob Kopacz > Cc: Tony Johansson; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > > Bob Kopacz wrote: > > >1. Johan's comment (paraphrased as I understand it) that what is really > >needed for issue#301 is for the AAAH to know the identity of the > >destination AAAF hosting the foreign HA. Although by requiring a fixed > >AAAH over the life of a MN's session, the AAAH can (with some effort) come > >up with the AAAF's identity, why not instead have the MN cache the > >destination AAAF's identity instead of the AAAH's identity? This > >eliminates the seemingly unnecessary restriction, and single point of > >failure, of a fixed AAAH. > > Yes, this was my still unanswered question. > It seems to me that if the HA's AAAF's Identity was added as another subtype for the AAA NAI extension, and if this information was returned to the MN instead of (or in addition to) the AAAH's identity, then this would meet the needs of issues #299 and #301. Matter of fact, feeding the Destination-AAAF's identity to the MN might be a good idea, anyway, as this would allow the session to continue if the AAAH became unavailable. > >On the other hand, a single AAAH does have some modest virtues: > >[a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new > >SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't > >change, the HA doesn't have to clear the session with the old AAAH when > >a new AAAH comes on board; [c] does session/policy/resource management > >become easier with a fixed AAAH? > > > > I agree with all of the above but I strongly disagree that it is > mandatory. They should all be perfectly allowable optimizations but > mandating them is unnecessary, removes an interesting degree of freedom > and most importantly forces external mechanisms to be used where none is > needed. I don't disagree with you here either. It is a judgement call. > j Take care, Bob K. From owner-aaa-wg@merit.edu Fri Apr 19 21:10:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28693 for ; Fri, 19 Apr 2002 21:10:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7114C912E0; Fri, 19 Apr 2002 21:10:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44A7A912E1; Fri, 19 Apr 2002 21:10:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42EEC912E0 for ; Fri, 19 Apr 2002 21:10:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 242CE5DDC5; Fri, 19 Apr 2002 21:10:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 765985DD90 for ; Fri, 19 Apr 2002 21:10:29 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Apr 2002 10:10:20 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A08399B@cms3.etri.re.kr> From: mariekim@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: Need information about redirect operation.. Date: Sat, 20 Apr 2002 10:10:15 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E808.212A0970" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E808.212A0970 Content-Type: text/plain; charset="euc-kr" Hi~ I'm about to implement a redirecting operation... But, unfortunately...I can't understand why a redirect-host avp may occur in only 3 msg, STA, ASA, RAA Is there any special reason? Is it impossible that AMA includes this avp? And, What is the redirect-max-cache-time setting policy? (in other words, How can I make redirect-max-cache-time setting policy?) Is there any information? I can't find any key about that...... Please help....me...... ------_=_NextPart_001_01C1E808.212A0970 Content-Type: text/html; charset="euc-kr" Need information about redirect operation..

Hi~
I'm about to implement a redirecting operation...
But, unfortunately...I can't understand why a redirect-host avp may occur in only 3 msg, STA, ASA, RAA
Is there any special reason? Is it impossible that AMA includes this avp?

And, What is the redirect-max-cache-time setting policy?
(in other words, How can I make redirect-max-cache-time setting policy?)
Is there any information?
I can't find any key about that......

Please help....me......

------_=_NextPart_001_01C1E808.212A0970-- From owner-aaa-wg@merit.edu Mon Apr 22 01:43:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08719 for ; Mon, 22 Apr 2002 01:43:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDB9D9122C; Mon, 22 Apr 2002 01:43:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFCE59122E; Mon, 22 Apr 2002 01:43:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B9B749122C for ; Mon, 22 Apr 2002 01:43:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81D355DE0B; Mon, 22 Apr 2002 01:43:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 0CE1C5DD96 for ; Mon, 22 Apr 2002 01:43:38 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M5hL0E016714 for ; Mon, 22 Apr 2002 07:43:22 +0200 (MEST) Received: FROM esealnt744.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 07:43:20 2002 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 07:43:21 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED2175@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Mon, 22 Apr 2002 07:43:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Mark, I totally agree with your proposal, we need the Vendor-Id inside. Regards, Miguel > -----Original Message----- > From: Mark Jones [mailto:mjones@bridgewatersystems.com] > Sent: Friday, April 19, 2002 12:11 PM > To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Miguel, > > To avoid result code collisions between vendors, I think the > new AVP needs > to include the Vendor-Id. > > Vendor-Specific-Result ::== < AVP Header: tbd > > { Vendor-Id } > { Vendor-Specific-Result-Code } > > where: > Vendor-Id: Datatype: Unsigned32; AVP code: 266 > Vendor-Specific-Result-Code: Datatype: Unsigned32; AVP > code: > > Alternatively, IANA gets another AVP to police but this > doesn't seem the > right approach for an AVP that is only used in > vendor-specific applications. > > Regards, > Mark > From owner-aaa-wg@merit.edu Mon Apr 22 04:01:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18705 for ; Mon, 22 Apr 2002 04:01:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2CD3D9122E; Mon, 22 Apr 2002 04:00:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4DD09122F; Mon, 22 Apr 2002 04:00:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D8909122E for ; Mon, 22 Apr 2002 04:00:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B27C5DE1B; Mon, 22 Apr 2002 04:00:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 6C18B5DD96 for ; Mon, 22 Apr 2002 04:00:33 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3M80nF28514 for ; Mon, 22 Apr 2002 11:00:49 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 11:00:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 11:00:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Date: Mon, 22 Apr 2002 11:00:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FA2@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: What is Result Cause Value ? In Multi-Failed AVP Case. Thread-Index: AcHnY4RsrenyxIYvSTCyqw3DgXFemQCcDVOw From: To: Cc: , , X-OriginalArrivalTime: 22 Apr 2002 08:00:30.0693 (UTC) FILETIME=[C5AD6150:01C1E9D3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA18705 Hi Jari, > Yes, I agree. But what I really meant was that the diameter > nodes should report the first error THEY encounter (could > be different by different implementations). I'm not sure we > explicitly state this anywhere at the moment. Hmm... checking... > how about changing the last paragraph of 7 from > > The Result-Code AVP contains additional errors conditions, and > defines the expected behavior of each. > > to > > The Result-Code AVP describes the error that the Diameter node > encountered in its processing. In case there are multiple errors, > the Diameter node MUST report only the first error it encountered > (detected possibly in some implementation dependent order). The > specific errors that can be described by this AVP are described in > the following section. That's reasonable, I've made the change. John From owner-aaa-wg@merit.edu Mon Apr 22 04:25:13 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19033 for ; Mon, 22 Apr 2002 04:25:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 577D891230; Mon, 22 Apr 2002 04:22:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AE9491234; Mon, 22 Apr 2002 04:22:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC9C591230 for ; Mon, 22 Apr 2002 04:22:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF0E45DE4A; Mon, 22 Apr 2002 04:22:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by segue.merit.edu (Postfix) with ESMTP id 2DB655DE32 for ; Mon, 22 Apr 2002 04:22:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Result codes in vendor specific applications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 2002 11:22:28 +0300 Message-ID: Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHnubM521bWhoG6TeiTJWAxPhKrlACHE4Vg From: "Sami Vaarala" To: "Mark Jones" , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA19033 Mark, >... > If we decide the Result-Code AVP is required in addition to the > Vendor-Specific-Result-Code, it also leaves developers with the question > "Which generic Result-Code is most appropriate for my vendor-specifc > problem?". This mapping may not always be obvious and so it will probably > not be done consistently (especially across different vendors). For each error category, add an error code that indicates a vendor-specific error of that category. But this point is moot if we don't send both a generic and a vendor specific result code. -Sami From owner-aaa-wg@merit.edu Mon Apr 22 09:16:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24684 for ; Mon, 22 Apr 2002 09:16:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC52891223; Mon, 22 Apr 2002 09:15:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE76091234; Mon, 22 Apr 2002 09:15:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8381591223 for ; Mon, 22 Apr 2002 09:15:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 619EB5DE2F; Mon, 22 Apr 2002 09:15:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 994355DDBC for ; Mon, 22 Apr 2002 09:15:32 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MDGZJ05451 for ; Mon, 22 Apr 2002 16:16:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 16:15:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 16:15:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Mon, 22 Apr 2002 16:15:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHnubM521bWhoG6TeiTJWAxPhKrlACHE4VgAApsheA= From: To: , , X-OriginalArrivalTime: 22 Apr 2002 13:15:27.0871 (UTC) FILETIME=[C545E8F0:01C1E9FF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24684 Sami & Mark, Could you document the text that should be added for this issue, otherwise I don't think that this can be added. John > -----Original Message----- > From: ext Sami Vaarala [mailto:sami.vaarala@netseal.com] > Sent: 22 April, 2002 11:22 > To: Mark Jones; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Mark, > > >... > > If we decide the Result-Code AVP is required in addition to the > > Vendor-Specific-Result-Code, it also leaves developers with the > question > > "Which generic Result-Code is most appropriate for my vendor-specifc > > problem?". This mapping may not always be obvious and so it will > probably > > not be done consistently (especially across different vendors). > > For each error category, add an error code that indicates a > vendor-specific > error of that category. But this point is moot if we don't > send both a > generic and a vendor specific result code. > > -Sami > > > From owner-aaa-wg@merit.edu Mon Apr 22 16:40:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12163 for ; Mon, 22 Apr 2002 16:40:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5625C91246; Mon, 22 Apr 2002 16:40:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2203B91248; Mon, 22 Apr 2002 16:40:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B96491246 for ; Mon, 22 Apr 2002 16:40:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D854D5DDC7; Mon, 22 Apr 2002 16:40:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 5BB635DD8D for ; Mon, 22 Apr 2002 16:40:27 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id QAA21789 for ; Mon, 22 Apr 2002 16:30:22 -0400 Received: from PRESTON ([192.168.149.28]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id QAA11999 for ; Mon, 22 Apr 2002 16:42:48 -0400 (EDT) From: "Mark Jones" To: Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Mon, 22 Apr 2002 16:44:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <577066326047D41180AC00508B955DDA05ED216B@eestqnt104> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As I stated earlier, my preference is for a single result code per message. If this is acceptable to the WG then building on Miguel-Angel's earlier text submission, the following changes are required to the Base protocol draft: --- Modify section 7.1, replacing: "All Diameter answer messages MUST include one Result-Code AVP" with "All Diameter answer messages defined in IETF applications MUST include one Result-Code AVP." --- Add two new sub-sections to section 7: 7.x Vendor-Specific-Result AVP The Vendor-Specific-Result AVP (AVP Code tbd) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. Its Data field has the following ABNF grammar: Vendor-Specific-Result ::= < AVP Header: tbd > { Vendor-Id } { Vendor-Specific-Result-Code } The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies the vendor responsible for the assignment of the result code which follows. All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Vendor-Specific-Result-Code AVP. 7.y Vendor-Specific-Result-Code AVP The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type Unsigned32 and contains a vendor-assigned value representing the result of processing the request. It is recommended that vendor-specific result codes follow the same conventions given for the Result-Code AVP regarding the different types of result codes and the handling of errors (for non 2xxx values). --- In chapter 4.6: After: ... Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | Application-Id | | | | | | Add: Vendor-Specific- TBD 7.x Grouped | M | P | | V | N | Result | | | | | | Vendor-Specific- TBD 7.y Unsigned32 | M | P | | V | N | Result-Code | | | | | | Regards, Mark From owner-aaa-wg@merit.edu Mon Apr 22 16:42:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12198 for ; Mon, 22 Apr 2002 16:42:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2218F91248; Mon, 22 Apr 2002 16:42:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC40591249; Mon, 22 Apr 2002 16:42:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F037291248 for ; Mon, 22 Apr 2002 16:42:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D83E35DDC7; Mon, 22 Apr 2002 16:41:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 9FBD35DD8D for ; Mon, 22 Apr 2002 16:41:44 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKfWw05245 for ; Tue, 23 Apr 2002 00:41:32 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5F79A82AB; Tue, 23 Apr 2002 00:41:26 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204126.5F79A82AB@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:41:26 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:43:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12253 for ; Mon, 22 Apr 2002 16:43:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7782391249; Mon, 22 Apr 2002 16:43:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 475049124A; Mon, 22 Apr 2002 16:43:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 495D591249 for ; Mon, 22 Apr 2002 16:43:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EC5F5DD8D; Mon, 22 Apr 2002 16:43:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 3E68D5DDC7 for ; Mon, 22 Apr 2002 16:43:09 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKgkw05337 for ; Tue, 23 Apr 2002 00:42:46 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 431A782BB; Tue, 23 Apr 2002 00:42:46 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204246.431A782BB@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:42:46 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:44:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12297 for ; Mon, 22 Apr 2002 16:44:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56E009124A; Mon, 22 Apr 2002 16:44:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22B9E9124B; Mon, 22 Apr 2002 16:44:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2098A9124A for ; Mon, 22 Apr 2002 16:44:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F368E5DDC7; Mon, 22 Apr 2002 16:44:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 517105DD8D for ; Mon, 22 Apr 2002 16:44:22 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKiDw05465 for ; Tue, 23 Apr 2002 00:44:13 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 156E4825E; Tue, 23 Apr 2002 00:44:13 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204413.156E4825E@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:44:13 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:46:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12349 for ; Mon, 22 Apr 2002 16:46:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B2409124B; Mon, 22 Apr 2002 16:45:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2C8E9124D; Mon, 22 Apr 2002 16:45:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C5CB9124B for ; Mon, 22 Apr 2002 16:45:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8125C5DDC7; Mon, 22 Apr 2002 16:45:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 2CED65DD8D for ; Mon, 22 Apr 2002 16:45:20 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKjFw05530 for ; Tue, 23 Apr 2002 00:45:15 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 3F772826C; Tue, 23 Apr 2002 00:45:15 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204515.3F772826C@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:45:15 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:47:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12390 for ; Mon, 22 Apr 2002 16:47:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 405E79124C; Mon, 22 Apr 2002 16:47:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 187019124D; Mon, 22 Apr 2002 16:47:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3DE59124C for ; Mon, 22 Apr 2002 16:47:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8264B5DD96; Mon, 22 Apr 2002 16:47:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 807785DD8D for ; Mon, 22 Apr 2002 16:47:02 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKkvw05638 for ; Tue, 23 Apr 2002 00:46:57 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 205698280; Tue, 23 Apr 2002 00:46:57 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204657.205698280@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:46:57 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:48:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12488 for ; Mon, 22 Apr 2002 16:48:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4704D9124D; Mon, 22 Apr 2002 16:48:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 182559124E; Mon, 22 Apr 2002 16:48:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA8859124D for ; Mon, 22 Apr 2002 16:48:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9A995DD96; Mon, 22 Apr 2002 16:48:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 93F255DD8D for ; Mon, 22 Apr 2002 16:48:04 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKluw05691 for ; Tue, 23 Apr 2002 00:47:56 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 392378287; Tue, 23 Apr 2002 00:47:56 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204756.392378287@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:47:56 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:49:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12522 for ; Mon, 22 Apr 2002 16:49:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23AFF91252; Mon, 22 Apr 2002 16:49:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4D7F9124F; Mon, 22 Apr 2002 16:49:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 904E79124E for ; Mon, 22 Apr 2002 16:49:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77F0C5DD96; Mon, 22 Apr 2002 16:49:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id A9F255DD8D for ; Mon, 22 Apr 2002 16:49:03 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKmvw05749 for ; Tue, 23 Apr 2002 00:48:57 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id E11208403; Tue, 23 Apr 2002 00:48:57 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204857.E11208403@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:48:57 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:50:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12556 for ; Mon, 22 Apr 2002 16:50:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A85C9124E; Mon, 22 Apr 2002 16:50:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A62B9124F; Mon, 22 Apr 2002 16:50:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C6129124E for ; Mon, 22 Apr 2002 16:50:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FF645DDC7; Mon, 22 Apr 2002 16:50:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 58A5A5DD96 for ; Mon, 22 Apr 2002 16:50:02 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKnsw05821 for ; Tue, 23 Apr 2002 00:49:54 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 10525830C; Tue, 23 Apr 2002 00:49:55 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204955.10525830C@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:49:55 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:51:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12587 for ; Mon, 22 Apr 2002 16:51:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 299C99124F; Mon, 22 Apr 2002 16:51:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E387291250; Mon, 22 Apr 2002 16:51:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 985239124F for ; Mon, 22 Apr 2002 16:51:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 796A75DD96; Mon, 22 Apr 2002 16:51:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id F05345DD8D for ; Mon, 22 Apr 2002 16:51:02 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKosw05991 for ; Tue, 23 Apr 2002 00:50:54 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id D2EF78319; Tue, 23 Apr 2002 00:50:54 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205054.D2EF78319@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:50:54 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:52:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12616 for ; Mon, 22 Apr 2002 16:52:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B24B91250; Mon, 22 Apr 2002 16:52:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F343D91253; Mon, 22 Apr 2002 16:52:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 010F791250 for ; Mon, 22 Apr 2002 16:52:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA9235DDD0; Mon, 22 Apr 2002 16:52:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E8B055DD8D for ; Mon, 22 Apr 2002 16:52:06 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKpqw06067 for ; Tue, 23 Apr 2002 00:51:52 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 3DAAD8435; Tue, 23 Apr 2002 00:51:52 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205152.3DAAD8435@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:51:52 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:53:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12671 for ; Mon, 22 Apr 2002 16:53:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFFF191254; Mon, 22 Apr 2002 16:53:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3EAE91253; Mon, 22 Apr 2002 16:53:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99A5991256 for ; Mon, 22 Apr 2002 16:53:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B4965DD96; Mon, 22 Apr 2002 16:53:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 3252B5DD8D for ; Mon, 22 Apr 2002 16:53:06 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKqxw06139 for ; Tue, 23 Apr 2002 00:52:59 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C44B98447; Tue, 23 Apr 2002 00:52:59 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205259.C44B98447@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:52:59 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:56:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12801 for ; Mon, 22 Apr 2002 16:56:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FBFD91260; Mon, 22 Apr 2002 16:54:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED97A91261; Mon, 22 Apr 2002 16:54:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85C929125D for ; Mon, 22 Apr 2002 16:54:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E3375DD96; Mon, 22 Apr 2002 16:54:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E982C5DD8D for ; Mon, 22 Apr 2002 16:54:06 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKrww06203 for ; Tue, 23 Apr 2002 00:53:58 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 886B38459; Tue, 23 Apr 2002 00:53:58 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205358.886B38459@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:53:58 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:57:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12840 for ; Mon, 22 Apr 2002 16:57:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B4DC91256; Mon, 22 Apr 2002 16:57:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD4639125E; Mon, 22 Apr 2002 16:57:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD35791256 for ; Mon, 22 Apr 2002 16:57:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B50575DD96; Mon, 22 Apr 2002 16:57:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 69DE45DD8D for ; Mon, 22 Apr 2002 16:57:21 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKvAw06412 for ; Tue, 23 Apr 2002 00:57:10 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 16A71848F; Tue, 23 Apr 2002 00:57:11 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205711.16A71848F@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:57:11 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 16:58:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12897 for ; Mon, 22 Apr 2002 16:58:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E63D9125E; Mon, 22 Apr 2002 16:58:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A23E9125D; Mon, 22 Apr 2002 16:58:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D149791261 for ; Mon, 22 Apr 2002 16:58:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96CB75DD96; Mon, 22 Apr 2002 16:58:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 06A1D5DD8D for ; Mon, 22 Apr 2002 16:58:24 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKwDw06471 for ; Tue, 23 Apr 2002 00:58:13 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5C12E81F4; Tue, 23 Apr 2002 00:58:13 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205813.5C12E81F4@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:58:13 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:00:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12926 for ; Mon, 22 Apr 2002 17:00:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 667DA9125D; Mon, 22 Apr 2002 16:59:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 324949125F; Mon, 22 Apr 2002 16:59:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 385D89125D for ; Mon, 22 Apr 2002 16:59:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CF745DD96; Mon, 22 Apr 2002 16:59:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 773E75DD8D for ; Mon, 22 Apr 2002 16:59:32 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKxNw06532 for ; Tue, 23 Apr 2002 00:59:23 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 9C46184B4; Tue, 23 Apr 2002 00:59:23 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422205923.9C46184B4@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:59:23 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:01:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12993 for ; Mon, 22 Apr 2002 17:01:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A773891262; Mon, 22 Apr 2002 17:00:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7339891263; Mon, 22 Apr 2002 17:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E33391262 for ; Mon, 22 Apr 2002 17:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F5015DD96; Mon, 22 Apr 2002 17:00:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E21BE5DD8D for ; Mon, 22 Apr 2002 17:00:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML0Qw06729 for ; Tue, 23 Apr 2002 01:00:26 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 188DD830B; Tue, 23 Apr 2002 01:00:26 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210026.188DD830B@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:00:26 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:02:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13065 for ; Mon, 22 Apr 2002 17:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C21AA91264; Mon, 22 Apr 2002 17:02:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9581891263; Mon, 22 Apr 2002 17:02:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D9229125F for ; Mon, 22 Apr 2002 17:02:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3F315DDA2; Mon, 22 Apr 2002 17:02:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id A06E25DD8D for ; Mon, 22 Apr 2002 17:02:07 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML1xw06847 for ; Tue, 23 Apr 2002 01:01:59 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5A7BA84E9; Tue, 23 Apr 2002 01:01:59 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210159.5A7BA84E9@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:01:59 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:03:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13095 for ; Mon, 22 Apr 2002 17:03:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 286BA91261; Mon, 22 Apr 2002 17:03:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E236491263; Mon, 22 Apr 2002 17:03:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D60E191261 for ; Mon, 22 Apr 2002 17:03:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3E9A5DDA2; Mon, 22 Apr 2002 17:03:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id EF5C95DD8D for ; Mon, 22 Apr 2002 17:03:10 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML33w06934 for ; Tue, 23 Apr 2002 01:03:03 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C572D84FA; Tue, 23 Apr 2002 01:03:03 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210303.C572D84FA@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:03:03 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:06:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13213 for ; Mon, 22 Apr 2002 17:06:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 384D89126A; Mon, 22 Apr 2002 17:04:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00DC691269; Mon, 22 Apr 2002 17:04:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 448CD91265 for ; Mon, 22 Apr 2002 17:04:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25B125DDC7; Mon, 22 Apr 2002 17:04:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 7EB165DDA2 for ; Mon, 22 Apr 2002 17:04:14 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML46w07006 for ; Tue, 23 Apr 2002 01:04:06 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id CFAFE80F3; Tue, 23 Apr 2002 01:04:06 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210406.CFAFE80F3@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:04:06 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:07:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13244 for ; Mon, 22 Apr 2002 17:07:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6FB591265; Mon, 22 Apr 2002 17:07:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94D7691266; Mon, 22 Apr 2002 17:07:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92C0491265 for ; Mon, 22 Apr 2002 17:07:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A81F5DDC7; Mon, 22 Apr 2002 17:07:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 17FBE5DD8D for ; Mon, 22 Apr 2002 17:07:28 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML7Kw07216 for ; Tue, 23 Apr 2002 01:07:20 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 715F88542; Tue, 23 Apr 2002 01:07:20 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210720.715F88542@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:07:20 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:08:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13268 for ; Mon, 22 Apr 2002 17:08:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC6D591266; Mon, 22 Apr 2002 17:08:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 742B691267; Mon, 22 Apr 2002 17:08:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 721A191266 for ; Mon, 22 Apr 2002 17:08:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A2C95DE0E; Mon, 22 Apr 2002 17:08:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C3A5C5DDC7 for ; Mon, 22 Apr 2002 17:08:24 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML8Hw07322 for ; Tue, 23 Apr 2002 01:08:18 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C255F8176; Tue, 23 Apr 2002 01:08:17 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210817.C255F8176@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:08:17 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:09:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13305 for ; Mon, 22 Apr 2002 17:09:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 388D791267; Mon, 22 Apr 2002 17:09:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 046A591268; Mon, 22 Apr 2002 17:09:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0249B91267 for ; Mon, 22 Apr 2002 17:09:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD4855DDC6; Mon, 22 Apr 2002 17:09:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 0C2185DD8D for ; Mon, 22 Apr 2002 17:09:23 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3ML9Ew07413 for ; Tue, 23 Apr 2002 01:09:14 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 38DCB8566; Tue, 23 Apr 2002 01:09:14 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422210914.38DCB8566@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:09:14 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:10:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13344 for ; Mon, 22 Apr 2002 17:10:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 674C891268; Mon, 22 Apr 2002 17:10:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B47791269; Mon, 22 Apr 2002 17:10:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A77691268 for ; Mon, 22 Apr 2002 17:10:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0E535DDC6; Mon, 22 Apr 2002 17:10:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 54B5F5DD8D for ; Mon, 22 Apr 2002 17:10:22 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLADw07623 for ; Tue, 23 Apr 2002 01:10:13 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6A24F8566; Tue, 23 Apr 2002 01:10:13 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211013.6A24F8566@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:10:13 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:11:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13383 for ; Mon, 22 Apr 2002 17:11:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 989FE91269; Mon, 22 Apr 2002 17:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 687949126B; Mon, 22 Apr 2002 17:11:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 666BA91269 for ; Mon, 22 Apr 2002 17:11:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45C5A5DDC7; Mon, 22 Apr 2002 17:11:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 3B6665DD8D for ; Mon, 22 Apr 2002 17:11:25 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLBGw07704 for ; Tue, 23 Apr 2002 01:11:16 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 30359824A; Tue, 23 Apr 2002 01:11:16 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211116.30359824A@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:11:16 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:12:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13414 for ; Mon, 22 Apr 2002 17:12:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53D299126B; Mon, 22 Apr 2002 17:12:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25B7A9126C; Mon, 22 Apr 2002 17:12:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BC519126B for ; Mon, 22 Apr 2002 17:12:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13EC05DDC7; Mon, 22 Apr 2002 17:12:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 0ABB15DD8D for ; Mon, 22 Apr 2002 17:12:26 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLCJw07786 for ; Tue, 23 Apr 2002 01:12:19 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 218E183FA; Tue, 23 Apr 2002 01:12:19 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211219.218E183FA@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:12:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:13:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13449 for ; Mon, 22 Apr 2002 17:13:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE8049126F; Mon, 22 Apr 2002 17:13:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5A009126E; Mon, 22 Apr 2002 17:13:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 400C29126D for ; Mon, 22 Apr 2002 17:13:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 213B05DD8D; Mon, 22 Apr 2002 17:13:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 2C3445DDC6 for ; Mon, 22 Apr 2002 17:13:17 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLD7w07861 for ; Tue, 23 Apr 2002 01:13:08 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id E87BF82C2; Tue, 23 Apr 2002 01:13:07 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211307.E87BF82C2@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:13:07 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:13:49 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13462 for ; Mon, 22 Apr 2002 17:13:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BFC19126C; Mon, 22 Apr 2002 17:13:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11B129126D; Mon, 22 Apr 2002 17:13:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DCF29126C for ; Mon, 22 Apr 2002 17:13:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 058F95DDD0; Mon, 22 Apr 2002 17:13:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 778655DDC7 for ; Mon, 22 Apr 2002 17:13:17 -0400 (EDT) Received: (qmail 1262 invoked by uid 500); 22 Apr 2002 21:13:16 -0000 Date: Mon, 22 Apr 2002 16:13:16 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)] Message-ID: <20020422211315.GX25507@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Whoever administers this list, please block spb.su from posting, since that seems to be the nearest domain of these spoofed e-mails. (If I'm reading the headers correctly) -Dave ----- Forwarded message from Mark Jones ----- Return-Path: Delivered-To: chaos@frascone.com Received: (qmail 423 invoked by alias); 22 Apr 2002 20:42:16 -0000 Delivered-To: dave@frascone.com Received: (qmail 420 invoked from network); 22 Apr 2002 20:42:16 -0000 Received: from trapdoor.merit.edu (postfix@198.108.1.26) by adsl-66-137-237-97.dsl.rcsntx.swbell.net with SMTP; 22 Apr 2002 20:42:16 -0000 Received: by trapdoor.merit.edu (Postfix) id 2218F91248; Mon, 22 Apr 2002 16:42:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC40591249; Mon, 22 Apr 2002 16:42:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F037291248 for ; Mon, 22 Apr 2002 16:42:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D83E35DDC7; Mon, 22 Apr 2002 16:41:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 9FBD35DD8D for ; Mon, 22 Apr 2002 16:41:44 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MKfWw05245 for ; Tue, 23 Apr 2002 00:41:32 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5F79A82AB; Tue, 23 Apr 2002 00:41:26 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422204126.5F79A82AB@rts.nio1.loniis> Date: Tue, 23 Apr 2002 00:41:26 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Status: No, hits=-99.0 required=5.0 tests=PLING,MAY_BE_FORGED,A_FROM_IN_AUTO_WLIST version=2.01 Status: RO Content-Length: 370 Lines: 5 ?????? ????????? ???? ????????? ?? ???????? ???????, ??? ??? ???????? ???????? ??????????????. ????????? ?????????? ? ?????? mjones@bridgewatersystems.com ?? ????? aaa-wg@merit.edu. ???? ?? ????????, ??? ?????? ????????? ?? ???????? ?????????????? ??? ??? ??? ?????????? ?? ????? ???? ?????? ????????, ?? ??? ?????????? ?????????? ? ?????? ???????? ??????????????. ----- End forwarded message ----- -- David Frascone I'm not schizophrenic. It's this guy beside me! From owner-aaa-wg@merit.edu Mon Apr 22 17:16:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13521 for ; Mon, 22 Apr 2002 17:16:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 929C09126E; Mon, 22 Apr 2002 17:14:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B8FD91273; Mon, 22 Apr 2002 17:14:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFA299126E for ; Mon, 22 Apr 2002 17:14:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69C95DDD0; Mon, 22 Apr 2002 17:14:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 79A055DD8D for ; Mon, 22 Apr 2002 17:14:21 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLEDw07960 for ; Tue, 23 Apr 2002 01:14:13 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id EC3A685B6; Tue, 23 Apr 2002 01:14:12 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211412.EC3A685B6@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:14:12 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:20:36 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13626 for ; Mon, 22 Apr 2002 17:20:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C73C291272; Mon, 22 Apr 2002 17:14:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F27D91274; Mon, 22 Apr 2002 17:14:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00FFB91272 for ; Mon, 22 Apr 2002 17:14:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD5695DD8D; Mon, 22 Apr 2002 17:14:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 0938B5DDC6 for ; Mon, 22 Apr 2002 17:14:23 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLEEw07964 for ; Tue, 23 Apr 2002 01:14:14 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 806948258; Tue, 23 Apr 2002 01:14:14 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)] RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211414.806948258@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:14:14 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:21:05 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13663 for ; Mon, 22 Apr 2002 17:21:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7801C91288; Mon, 22 Apr 2002 17:18:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFD6B91287; Mon, 22 Apr 2002 17:18:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 905CE91288 for ; Mon, 22 Apr 2002 17:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 75E6B5DD96; Mon, 22 Apr 2002 17:17:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E48D85DD8D for ; Mon, 22 Apr 2002 17:17:46 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLHdw08178 for ; Tue, 23 Apr 2002 01:17:39 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 8A71183C5; Tue, 23 Apr 2002 01:17:39 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422211739.8A71183C5@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:17:39 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:21:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13664 for ; Mon, 22 Apr 2002 17:21:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5B8D91294; Mon, 22 Apr 2002 17:20:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70B4D91289; Mon, 22 Apr 2002 17:20:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0536B91294 for ; Mon, 22 Apr 2002 17:20:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D10A15DD96; Mon, 22 Apr 2002 17:20:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 32C3A5DD8D for ; Mon, 22 Apr 2002 17:20:01 -0400 (EDT) Received: (qmail 1434 invoked by uid 500); 22 Apr 2002 21:20:00 -0000 Date: Mon, 22 Apr 2002 16:20:00 -0500 From: David Frascone To: "aaa-wg@merit.edu" Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?= =?unknown-8bit?Q?ersystems=2Ecom=3A_RE=3A_=5BAAA-WG=5D=3A_Result_codes_in?= =?unknown-8bit?B?IHZlbmRvciBzcGVjaWZpYyBhcHBsaWNhdGlvbnMoPz8/Pz8/Pz8/ID8/?= =?unknown-8bit?B?Pz8/ISldIFJFOiBbQUFBLVdHXTogUmVzdWx0IGNvZGVzIGluIHZlbmRv?= =?unknown-8bit?B?ciBzcGVjaWZpYyBhcHBsaWNhdGlvbnMo78LOwdLV1sXOINfJ0tXTISko?= =?unknown-8bit?B?78LOwdLV1sXOINfJ0tXTISk=?= Message-ID: <20020422212000.GZ25507@newman.frascone.com> Mail-Followup-To: "aaa-wg@merit.edu" References: <20020422211414.806948258@rts.nio1.loniis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020422211414.806948258@rts.nio1.loniis> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Great. Now I'm the spammer :( On Tuesday, 23 Apr 2002, Mark Jones wrote: > ?????? ????????? ???? ????????? ?? ???????? ???????, ??? ??? ???????? > ???????? ??????????????. ????????? ?????????? ? ?????? dave@frascone.com ?? ????? aaa-wg@merit.edu. > ???? ?? ????????, ??? ?????? ????????? ?? ???????? ?????????????? ??? ??? ??? ?????????? ?? ????? > ???? ?????? ????????, ?? ??? ?????????? ?????????? ? ?????? ???????? ??????????????. > -- David Frascone Hey, Worf...I hooked Data up to a Modem...Wanna see? From owner-aaa-wg@merit.edu Mon Apr 22 17:21:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13698 for ; Mon, 22 Apr 2002 17:21:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9FA191282; Mon, 22 Apr 2002 17:21:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A32DE912A6; Mon, 22 Apr 2002 17:21:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FCA791282 for ; Mon, 22 Apr 2002 17:21:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FA695DD96; Mon, 22 Apr 2002 17:21:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E42495DD8D for ; Mon, 22 Apr 2002 17:21:04 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLKsw08479 for ; Tue, 23 Apr 2002 01:20:54 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 9856D860D; Tue, 23 Apr 2002 01:20:54 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212054.9856D860D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:20:54 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:22:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13743 for ; Mon, 22 Apr 2002 17:22:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E31B391273; Mon, 22 Apr 2002 17:21:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A92B91275; Mon, 22 Apr 2002 17:21:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1BC291273 for ; Mon, 22 Apr 2002 17:21:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68A0B5DD96; Mon, 22 Apr 2002 17:21:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id DFBA65DD8D for ; Mon, 22 Apr 2002 17:21:32 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLLKw08515 for ; Tue, 23 Apr 2002 01:21:20 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 06C86861B; Tue, 23 Apr 2002 01:21:21 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212121.06C86861B@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:21:21 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:23:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13778 for ; Mon, 22 Apr 2002 17:23:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5385C91274; Mon, 22 Apr 2002 17:22:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA9E991276; Mon, 22 Apr 2002 17:22:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A8E291274 for ; Mon, 22 Apr 2002 17:22:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F2045DD8D; Mon, 22 Apr 2002 17:22:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 7BC645DDC6 for ; Mon, 22 Apr 2002 17:21:59 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLLow08549 for ; Tue, 23 Apr 2002 01:21:50 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 729A281A8; Tue, 23 Apr 2002 01:21:48 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212148.729A281A8@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:21:48 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:24:06 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13841 for ; Mon, 22 Apr 2002 17:24:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 050319127A; Mon, 22 Apr 2002 17:23:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78F0291293; Mon, 22 Apr 2002 17:23:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 725729127A for ; Mon, 22 Apr 2002 17:23:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F1525DD8D; Mon, 22 Apr 2002 17:23:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C08525DDA2 for ; Mon, 22 Apr 2002 17:22:55 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLMjw08614 for ; Tue, 23 Apr 2002 01:22:45 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 2F7558633; Tue, 23 Apr 2002 01:22:44 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212244.2F7558633@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:22:44 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:24:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13835 for ; Mon, 22 Apr 2002 17:24:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F43991284; Mon, 22 Apr 2002 17:23:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C48239128D; Mon, 22 Apr 2002 17:23:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B312291284 for ; Mon, 22 Apr 2002 17:22:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D22C5DDA2; Mon, 22 Apr 2002 17:22:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 70AB35DD8D for ; Mon, 22 Apr 2002 17:22:33 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLMLw08586 for ; Tue, 23 Apr 2002 01:22:21 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 192AB8060; Tue, 23 Apr 2002 01:22:20 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212220.192AB8060@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:22:20 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:24:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13914 for ; Mon, 22 Apr 2002 17:24:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2D4D91270; Mon, 22 Apr 2002 17:24:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4B1B91271; Mon, 22 Apr 2002 17:24:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD12C91270 for ; Mon, 22 Apr 2002 17:24:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C7AD5DE0E; Mon, 22 Apr 2002 17:24:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 484A75DD8D for ; Mon, 22 Apr 2002 17:24:05 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLNtw08699 for ; Tue, 23 Apr 2002 01:23:55 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 7DC49844D; Tue, 23 Apr 2002 01:23:53 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212353.7DC49844D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:23:53 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:24:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13929 for ; Mon, 22 Apr 2002 17:24:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB78091271; Mon, 22 Apr 2002 17:24:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F64091275; Mon, 22 Apr 2002 17:24:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F5AE91271 for ; Mon, 22 Apr 2002 17:24:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 751CB5DE1C; Mon, 22 Apr 2002 17:24:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1D4795DD8D for ; Mon, 22 Apr 2002 17:24:33 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLOLw08735 for ; Tue, 23 Apr 2002 01:24:21 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id BE58B828E; Tue, 23 Apr 2002 01:24:19 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212419.BE58B828E@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:24:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:25:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13982 for ; Mon, 22 Apr 2002 17:25:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1ACEF91276; Mon, 22 Apr 2002 17:24:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A565F91277; Mon, 22 Apr 2002 17:24:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 943D891276 for ; Mon, 22 Apr 2002 17:24:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AD975DD8D; Mon, 22 Apr 2002 17:24:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id D251C5DDC6 for ; Mon, 22 Apr 2002 17:24:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLONw08742 for ; Tue, 23 Apr 2002 01:24:23 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id E55128472; Tue, 23 Apr 2002 01:24:21 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212421.E55128472@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:24:21 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:25:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14014 for ; Mon, 22 Apr 2002 17:25:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6109791275; Mon, 22 Apr 2002 17:25:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30D7691277; Mon, 22 Apr 2002 17:25:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4321A91275 for ; Mon, 22 Apr 2002 17:25:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A2655DD8D; Mon, 22 Apr 2002 17:25:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C714A5DDD0 for ; Mon, 22 Apr 2002 17:25:15 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLP5w08789 for ; Tue, 23 Apr 2002 01:25:05 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 3EE5E8638; Tue, 23 Apr 2002 01:25:04 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212504.3EE5E8638@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:25:04 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:26:20 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14079 for ; Mon, 22 Apr 2002 17:26:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1298691277; Mon, 22 Apr 2002 17:25:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D482B91279; Mon, 22 Apr 2002 17:25:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C0D091277 for ; Mon, 22 Apr 2002 17:25:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 140715DDD0; Mon, 22 Apr 2002 17:25:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C05E45DDC6 for ; Mon, 22 Apr 2002 17:25:41 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLPVw08818 for ; Tue, 23 Apr 2002 01:25:31 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 2DC11865A; Tue, 23 Apr 2002 01:25:30 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212530.2DC11865A@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:25:30 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:26:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14143 for ; Mon, 22 Apr 2002 17:26:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16CF09127C; Mon, 22 Apr 2002 17:26:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D834C9127D; Mon, 22 Apr 2002 17:26:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B8CFD9127C for ; Mon, 22 Apr 2002 17:26:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FFBA5DDC6; Mon, 22 Apr 2002 17:26:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 38C205DD8D for ; Mon, 22 Apr 2002 17:26:40 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLQYw08907 for ; Tue, 23 Apr 2002 01:26:34 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id B2D638669; Tue, 23 Apr 2002 01:26:32 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212632.B2D638669@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:26:32 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:26:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14140 for ; Mon, 22 Apr 2002 17:26:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C5889127B; Mon, 22 Apr 2002 17:26:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A3589127C; Mon, 22 Apr 2002 17:26:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 307849127B for ; Mon, 22 Apr 2002 17:26:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 125205DD8D; Mon, 22 Apr 2002 17:26:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 9A3955DDC6 for ; Mon, 22 Apr 2002 17:26:25 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLQEw08877 for ; Tue, 23 Apr 2002 01:26:14 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 542318638; Tue, 23 Apr 2002 01:26:12 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212612.542318638@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:26:12 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:27:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14192 for ; Mon, 22 Apr 2002 17:27:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01E939127F; Mon, 22 Apr 2002 17:27:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C75C89127E; Mon, 22 Apr 2002 17:27:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58CD59127D for ; Mon, 22 Apr 2002 17:27:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E0795DDD0; Mon, 22 Apr 2002 17:27:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 4D96F5DD8D for ; Mon, 22 Apr 2002 17:26:52 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLQhw08919 for ; Tue, 23 Apr 2002 01:26:43 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 34470866A; Tue, 23 Apr 2002 01:26:42 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212642.34470866A@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:26:42 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:27:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14218 for ; Mon, 22 Apr 2002 17:27:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41A7F9127D; Mon, 22 Apr 2002 17:27:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 178B79127E; Mon, 22 Apr 2002 17:27:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BDF39127D for ; Mon, 22 Apr 2002 17:27:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05B1A5DE1C; Mon, 22 Apr 2002 17:27:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 519855DD8D for ; Mon, 22 Apr 2002 17:27:28 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLRLw08957 for ; Tue, 23 Apr 2002 01:27:21 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id F0D448662; Tue, 23 Apr 2002 01:27:19 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212719.F0D448662@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:27:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:28:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14254 for ; Mon, 22 Apr 2002 17:28:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 12B9791281; Mon, 22 Apr 2002 17:28:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E046291280; Mon, 22 Apr 2002 17:28:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 504FF91289 for ; Mon, 22 Apr 2002 17:28:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 974FD5DE50; Mon, 22 Apr 2002 17:28:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 4A00A5DD8D for ; Mon, 22 Apr 2002 17:28:04 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLRqw08992 for ; Tue, 23 Apr 2002 01:27:52 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 2658A8674; Tue, 23 Apr 2002 01:27:51 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212751.2658A8674@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:27:51 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:28:37 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14266 for ; Mon, 22 Apr 2002 17:28:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 023689127E; Mon, 22 Apr 2002 17:28:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC08B91280; Mon, 22 Apr 2002 17:28:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D55F9127E for ; Mon, 22 Apr 2002 17:28:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 754615DDC6; Mon, 22 Apr 2002 17:28:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 6FB555DDD0 for ; Mon, 22 Apr 2002 17:27:52 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLRew08982 for ; Tue, 23 Apr 2002 01:27:40 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 43B498677; Tue, 23 Apr 2002 01:27:39 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212739.43B498677@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:27:39 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:29:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14289 for ; Mon, 22 Apr 2002 17:29:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9227E91283; Mon, 22 Apr 2002 17:28:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61CE591280; Mon, 22 Apr 2002 17:28:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2119F91283 for ; Mon, 22 Apr 2002 17:28:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC8015DD8D; Mon, 22 Apr 2002 17:28:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id A13DC5DDD0 for ; Mon, 22 Apr 2002 17:28:42 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLSVw09049 for ; Tue, 23 Apr 2002 01:28:31 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id F2B9C8685; Tue, 23 Apr 2002 01:28:29 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212829.F2B9C8685@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:28:29 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:29:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14321 for ; Mon, 22 Apr 2002 17:29:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8537291280; Mon, 22 Apr 2002 17:29:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52D6D91285; Mon, 22 Apr 2002 17:29:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 550A891280 for ; Mon, 22 Apr 2002 17:29:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B0C75DD8D; Mon, 22 Apr 2002 17:29:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 62B355DE1C for ; Mon, 22 Apr 2002 17:29:02 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLSnw09077 for ; Tue, 23 Apr 2002 01:28:49 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 8DD6582AC; Tue, 23 Apr 2002 01:28:47 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212847.8DD6582AC@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:28:47 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:29:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14341 for ; Mon, 22 Apr 2002 17:29:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C689491289; Mon, 22 Apr 2002 17:29:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 900A891287; Mon, 22 Apr 2002 17:29:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 212BE91285 for ; Mon, 22 Apr 2002 17:29:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04AB55DDD0; Mon, 22 Apr 2002 17:29:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 80BEA5DD8D for ; Mon, 22 Apr 2002 17:29:16 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLT5w09097 for ; Tue, 23 Apr 2002 01:29:05 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 2823D8491; Tue, 23 Apr 2002 01:29:04 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212904.2823D8491@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:29:04 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:31:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14404 for ; Mon, 22 Apr 2002 17:31:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E8A89128B; Mon, 22 Apr 2002 17:30:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88B5F9128A; Mon, 22 Apr 2002 17:30:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9225891287 for ; Mon, 22 Apr 2002 17:30:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B8CA5DDC6; Mon, 22 Apr 2002 17:30:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1FF675DD8D for ; Mon, 22 Apr 2002 17:30:00 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLTlw09159 for ; Tue, 23 Apr 2002 01:29:47 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id DD5CC8498; Tue, 23 Apr 2002 01:29:46 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212946.DD5CC8498@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:29:46 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:31:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14440 for ; Mon, 22 Apr 2002 17:31:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 130809128A; Mon, 22 Apr 2002 17:30:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4E939128E; Mon, 22 Apr 2002 17:30:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8C059128A for ; Mon, 22 Apr 2002 17:30:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87B7E5DD8D; Mon, 22 Apr 2002 17:30:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 879755DE1C for ; Mon, 22 Apr 2002 17:30:05 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLTsw09173 for ; Tue, 23 Apr 2002 01:29:54 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id DD78F8416; Tue, 23 Apr 2002 01:29:53 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212953.DD78F8416@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:29:53 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:32:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14473 for ; Mon, 22 Apr 2002 17:31:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2A319128F; Mon, 22 Apr 2002 17:30:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B461591293; Mon, 22 Apr 2002 17:30:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7823D9128F for ; Mon, 22 Apr 2002 17:30:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BEA45DD8D; Mon, 22 Apr 2002 17:30:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 38D055DDC6 for ; Mon, 22 Apr 2002 17:30:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLUKw09330 for ; Tue, 23 Apr 2002 01:30:20 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 0BE1E820C; Tue, 23 Apr 2002 01:30:20 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213020.0BE1E820C@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:30:20 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:32:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14512 for ; Mon, 22 Apr 2002 17:32:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29C0F91287; Mon, 22 Apr 2002 17:32:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1A2991285; Mon, 22 Apr 2002 17:32:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D76A91287 for ; Mon, 22 Apr 2002 17:32:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 236DF5DDC6; Mon, 22 Apr 2002 17:32:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 7449C5DD96 for ; Mon, 22 Apr 2002 17:32:00 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLVow09459 for ; Tue, 23 Apr 2002 01:31:50 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id A913C8431; Tue, 23 Apr 2002 01:31:49 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213149.A913C8431@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:31:49 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:33:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14551 for ; Mon, 22 Apr 2002 17:33:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C5D09129A; Mon, 22 Apr 2002 17:33:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C607591295; Mon, 22 Apr 2002 17:32:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57DC691285 for ; Mon, 22 Apr 2002 17:32:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 373345DDC6; Mon, 22 Apr 2002 17:32:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 391DF5DD96 for ; Mon, 22 Apr 2002 17:32:20 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLWAw09494 for ; Tue, 23 Apr 2002 01:32:10 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 15739823D; Tue, 23 Apr 2002 01:32:10 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213210.15739823D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:32:10 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:34:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14579 for ; Mon, 22 Apr 2002 17:34:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F82191295; Mon, 22 Apr 2002 17:33:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8657F9128E; Mon, 22 Apr 2002 17:33:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2488F9129B for ; Mon, 22 Apr 2002 17:33:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 013465DDC6; Mon, 22 Apr 2002 17:33:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id F16335DD96 for ; Mon, 22 Apr 2002 17:33:02 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLWsw09559 for ; Tue, 23 Apr 2002 01:32:54 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id A9FDD86B4; Tue, 23 Apr 2002 01:32:53 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213253.A9FDD86B4@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:32:53 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:34:10 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14592 for ; Mon, 22 Apr 2002 17:34:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0156291293; Mon, 22 Apr 2002 17:33:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A7A29128D; Mon, 22 Apr 2002 17:33:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3174591298 for ; Mon, 22 Apr 2002 17:32:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A8C65DDD0; Mon, 22 Apr 2002 17:32:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 09A325DDC6 for ; Mon, 22 Apr 2002 17:32:41 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLWYw09529 for ; Tue, 23 Apr 2002 01:32:34 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6272D86B7; Tue, 23 Apr 2002 01:32:33 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213233.6272D86B7@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:32:33 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:35:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14634 for ; Mon, 22 Apr 2002 17:35:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 657B691285; Mon, 22 Apr 2002 17:34:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 393189128D; Mon, 22 Apr 2002 17:34:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B66091285 for ; Mon, 22 Apr 2002 17:34:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 203F55DDC6; Mon, 22 Apr 2002 17:34:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 500975DD96 for ; Mon, 22 Apr 2002 17:34:33 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLYHw09648 for ; Tue, 23 Apr 2002 01:34:17 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id EF02C86BE; Tue, 23 Apr 2002 01:34:16 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213416.EF02C86BE@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:34:16 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:35:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14655 for ; Mon, 22 Apr 2002 17:35:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0761191291; Mon, 22 Apr 2002 17:35:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCDD39128E; Mon, 22 Apr 2002 17:35:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64E729128D for ; Mon, 22 Apr 2002 17:35:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CA3B5DDD0; Mon, 22 Apr 2002 17:35:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1598A5DD96 for ; Mon, 22 Apr 2002 17:34:51 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLYZw09681 for ; Tue, 23 Apr 2002 01:34:35 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 90A0E81A6; Tue, 23 Apr 2002 01:34:34 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213434.90A0E81A6@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:34:34 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:35:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14675 for ; Mon, 22 Apr 2002 17:35:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A97C09128D; Mon, 22 Apr 2002 17:35:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 238C791299; Mon, 22 Apr 2002 17:35:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F8B89128D for ; Mon, 22 Apr 2002 17:35:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63F585DD96; Mon, 22 Apr 2002 17:35:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 769295DDC6 for ; Mon, 22 Apr 2002 17:34:59 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLYhw09686 for ; Tue, 23 Apr 2002 01:34:43 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id BE6C786C1; Tue, 23 Apr 2002 01:34:42 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213442.BE6C786C1@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:34:42 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:36:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14703 for ; Mon, 22 Apr 2002 17:36:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE3C49128E; Mon, 22 Apr 2002 17:36:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9F3091296; Mon, 22 Apr 2002 17:36:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE0F09128E for ; Mon, 22 Apr 2002 17:36:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A48925DDC6; Mon, 22 Apr 2002 17:36:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 4A58D5DD96 for ; Mon, 22 Apr 2002 17:35:55 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLZiw09757 for ; Tue, 23 Apr 2002 01:35:44 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6A316845C; Tue, 23 Apr 2002 01:35:43 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213543.6A316845C@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:35:43 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:36:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14715 for ; Mon, 22 Apr 2002 17:36:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5771691297; Mon, 22 Apr 2002 17:36:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E417691299; Mon, 22 Apr 2002 17:36:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A17391297 for ; Mon, 22 Apr 2002 17:36:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FDE45DE32; Mon, 22 Apr 2002 17:36:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 886A55DDC6 for ; Mon, 22 Apr 2002 17:36:12 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLa4w09796 for ; Tue, 23 Apr 2002 01:36:04 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 1CD2486E0; Tue, 23 Apr 2002 01:36:04 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213604.1CD2486E0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:36:04 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:36:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14739 for ; Mon, 22 Apr 2002 17:36:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 673CE91299; Mon, 22 Apr 2002 17:36:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BE44912A0; Mon, 22 Apr 2002 17:36:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4888E91299 for ; Mon, 22 Apr 2002 17:36:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 313315DDC6; Mon, 22 Apr 2002 17:36:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 515D05DD96 for ; Mon, 22 Apr 2002 17:36:20 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLaDw09817 for ; Tue, 23 Apr 2002 01:36:13 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 7675884CC; Tue, 23 Apr 2002 01:36:12 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213612.7675884CC@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:36:12 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:37:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14792 for ; Mon, 22 Apr 2002 17:37:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B92699129B; Mon, 22 Apr 2002 17:37:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8550D91298; Mon, 22 Apr 2002 17:37:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96B559129B for ; Mon, 22 Apr 2002 17:37:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C3A35DE4A; Mon, 22 Apr 2002 17:37:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 303515DD96 for ; Mon, 22 Apr 2002 17:37:29 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLbCw09883 for ; Tue, 23 Apr 2002 01:37:12 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 8DEDC8224; Tue, 23 Apr 2002 01:37:11 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213711.8DEDC8224@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:37:11 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:38:00 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14811 for ; Mon, 22 Apr 2002 17:38:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B65191296; Mon, 22 Apr 2002 17:37:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E919D91298; Mon, 22 Apr 2002 17:37:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B88E591296 for ; Mon, 22 Apr 2002 17:37:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D0D45DDC6; Mon, 22 Apr 2002 17:37:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 978E35DD96 for ; Mon, 22 Apr 2002 17:37:10 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLarw09868 for ; Tue, 23 Apr 2002 01:36:53 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 4482F824D; Tue, 23 Apr 2002 01:36:53 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213653.4482F824D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:36:53 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:38:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14841 for ; Mon, 22 Apr 2002 17:38:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32AB99129D; Mon, 22 Apr 2002 17:37:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0809D91298; Mon, 22 Apr 2002 17:37:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FFD99129C for ; Mon, 22 Apr 2002 17:37:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 348FB5DE4E; Mon, 22 Apr 2002 17:37:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C2B555DD96 for ; Mon, 22 Apr 2002 17:37:39 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLbWw09905 for ; Tue, 23 Apr 2002 01:37:32 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6BD69845D; Tue, 23 Apr 2002 01:37:31 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213731.6BD69845D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:37:31 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:39:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14869 for ; Mon, 22 Apr 2002 17:38:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B3AE91298; Mon, 22 Apr 2002 17:38:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF0629129C; Mon, 22 Apr 2002 17:38:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E548991298 for ; Mon, 22 Apr 2002 17:38:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC86C5DDC6; Mon, 22 Apr 2002 17:38:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 6BB435DD96 for ; Mon, 22 Apr 2002 17:38:27 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLcHw09984 for ; Tue, 23 Apr 2002 01:38:17 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id DCBBC8465; Tue, 23 Apr 2002 01:38:16 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213816.DCBBC8465@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:38:16 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:39:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14896 for ; Mon, 22 Apr 2002 17:39:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17649912A6; Mon, 22 Apr 2002 17:38:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAE34912A1; Mon, 22 Apr 2002 17:38:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B624912A0 for ; Mon, 22 Apr 2002 17:38:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DCF8C5DD96; Mon, 22 Apr 2002 17:38:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 6B18A5DDC6 for ; Mon, 22 Apr 2002 17:38:45 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLcXw10010 for ; Tue, 23 Apr 2002 01:38:33 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id E569086F9; Tue, 23 Apr 2002 01:38:32 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213832.E569086F9@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:38:32 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:39:19 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14908 for ; Mon, 22 Apr 2002 17:39:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 312279129C; Mon, 22 Apr 2002 17:38:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC23D9129E; Mon, 22 Apr 2002 17:38:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 441F7912A4 for ; Mon, 22 Apr 2002 17:38:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 255005DDC6; Mon, 22 Apr 2002 17:38:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id F3B935DD96 for ; Mon, 22 Apr 2002 17:38:35 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLcTw10001 for ; Tue, 23 Apr 2002 01:38:29 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 57256846D; Tue, 23 Apr 2002 01:38:28 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213828.57256846D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:38:28 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:40:09 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15023 for ; Mon, 22 Apr 2002 17:40:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7758D9129E; Mon, 22 Apr 2002 17:39:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49268912A0; Mon, 22 Apr 2002 17:39:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C8A09129E for ; Mon, 22 Apr 2002 17:39:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 001CA5DDD0; Mon, 22 Apr 2002 17:39:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 086FE5DD96 for ; Mon, 22 Apr 2002 17:39:30 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLdJw10077 for ; Tue, 23 Apr 2002 01:39:19 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 08EB78223; Tue, 23 Apr 2002 01:39:19 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213919.08EB78223@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:39:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:40:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15044 for ; Mon, 22 Apr 2002 17:40:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C0D0912A2; Mon, 22 Apr 2002 17:39:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9B68912A3; Mon, 22 Apr 2002 17:39:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E36F9912A1 for ; Mon, 22 Apr 2002 17:39:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C4F005DDC6; Mon, 22 Apr 2002 17:39:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id BF6155DD96 for ; Mon, 22 Apr 2002 17:39:45 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLdbw10102 for ; Tue, 23 Apr 2002 01:39:37 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id AB19A8712; Tue, 23 Apr 2002 01:39:36 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213936.AB19A8712@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:39:36 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:40:21 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15062 for ; Mon, 22 Apr 2002 17:40:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF8E0912A0; Mon, 22 Apr 2002 17:39:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A90A7912A1; Mon, 22 Apr 2002 17:39:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A835912A0 for ; Mon, 22 Apr 2002 17:39:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17C2E5DDD0; Mon, 22 Apr 2002 17:39:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 9AABF5DDC6 for ; Mon, 22 Apr 2002 17:39:35 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLdPw10087 for ; Tue, 23 Apr 2002 01:39:25 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 85C8084DA; Tue, 23 Apr 2002 01:39:24 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422213924.85C8084DA@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:39:24 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:41:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15094 for ; Mon, 22 Apr 2002 17:41:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48DDB912A1; Mon, 22 Apr 2002 17:40:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 084A6912A3; Mon, 22 Apr 2002 17:40:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7CF1912A1 for ; Mon, 22 Apr 2002 17:40:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B10285DDD0; Mon, 22 Apr 2002 17:40:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 540385DD96 for ; Mon, 22 Apr 2002 17:40:31 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLeLw10267 for ; Tue, 23 Apr 2002 01:40:21 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 79D0584F4; Tue, 23 Apr 2002 01:40:19 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214019.79D0584F4@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:40:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:41:27 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15121 for ; Mon, 22 Apr 2002 17:41:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D47F3912A4; Mon, 22 Apr 2002 17:40:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91838912A7; Mon, 22 Apr 2002 17:40:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E2D4912A5 for ; Mon, 22 Apr 2002 17:40:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 745F35DD96; Mon, 22 Apr 2002 17:40:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 5BDEA5DDC6 for ; Mon, 22 Apr 2002 17:40:40 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLeWw10287 for ; Tue, 23 Apr 2002 01:40:32 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id EFA97871D; Tue, 23 Apr 2002 01:40:30 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214030.EFA97871D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:40:30 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:41:43 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15135 for ; Mon, 22 Apr 2002 17:41:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 937E7912A5; Mon, 22 Apr 2002 17:41:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11F14912AF; Mon, 22 Apr 2002 17:41:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DBBA912A5 for ; Mon, 22 Apr 2002 17:41:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69FEB5DDD0; Mon, 22 Apr 2002 17:41:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 390E15DDC6 for ; Mon, 22 Apr 2002 17:40:54 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLelw10307 for ; Tue, 23 Apr 2002 01:40:47 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 0B18E8714; Tue, 23 Apr 2002 01:40:46 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214046.0B18E8714@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:40:46 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:44:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15209 for ; Mon, 22 Apr 2002 17:44:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9CC9912AB; Mon, 22 Apr 2002 17:42:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7733912AC; Mon, 22 Apr 2002 17:42:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE0AA912AB for ; Mon, 22 Apr 2002 17:41:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D10935DDC6; Mon, 22 Apr 2002 17:41:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1DA2A5DD96 for ; Mon, 22 Apr 2002 17:41:37 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLfQw10364 for ; Tue, 23 Apr 2002 01:41:26 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 9FC28872B; Tue, 23 Apr 2002 01:41:24 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214124.9FC28872B@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:41:24 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:45:03 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15247 for ; Mon, 22 Apr 2002 17:45:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42B29912B1; Mon, 22 Apr 2002 17:42:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14015912B0; Mon, 22 Apr 2002 17:42:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C6A2912AE for ; Mon, 22 Apr 2002 17:42:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23E3E5DDC6; Mon, 22 Apr 2002 17:42:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1FB535DD96 for ; Mon, 22 Apr 2002 17:42:05 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLfew10384 for ; Tue, 23 Apr 2002 01:41:40 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id B4B2B8502; Tue, 23 Apr 2002 01:41:38 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214138.B4B2B8502@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:41:38 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:45:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15259 for ; Mon, 22 Apr 2002 17:45:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA225912B0; Mon, 22 Apr 2002 17:42:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9786A912C8; Mon, 22 Apr 2002 17:42:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9787F912B0 for ; Mon, 22 Apr 2002 17:42:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7513E5DE32; Mon, 22 Apr 2002 17:42:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 22C315DDD0 for ; Mon, 22 Apr 2002 17:42:24 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLfww10412 for ; Tue, 23 Apr 2002 01:41:58 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 89A0D8734; Tue, 23 Apr 2002 01:41:56 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214156.89A0D8734@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:41:56 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:46:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15335 for ; Mon, 22 Apr 2002 17:46:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7BB62912E6; Mon, 22 Apr 2002 17:45:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0855C912C9; Mon, 22 Apr 2002 17:45:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 799CB912DE for ; Mon, 22 Apr 2002 17:45:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CAF635DDC6; Mon, 22 Apr 2002 17:45:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 4691D5DE5E for ; Mon, 22 Apr 2002 17:45:08 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLj2w10643 for ; Tue, 23 Apr 2002 01:45:02 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C097B8759; Tue, 23 Apr 2002 01:45:00 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214500.C097B8759@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:45:00 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:46:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15354 for ; Mon, 22 Apr 2002 17:46:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F6A5912ED; Mon, 22 Apr 2002 17:45:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 270DC912C9; Mon, 22 Apr 2002 17:45:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC939912ED for ; Mon, 22 Apr 2002 17:45:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA75E5DE1C; Mon, 22 Apr 2002 17:45:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 2CE3F5DDC6 for ; Mon, 22 Apr 2002 17:45:30 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLjKw10668 for ; Tue, 23 Apr 2002 01:45:20 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 4D6C0875E; Tue, 23 Apr 2002 01:45:19 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214519.4D6C0875E@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:45:19 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:47:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15373 for ; Mon, 22 Apr 2002 17:47:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8850E912C9; Mon, 22 Apr 2002 17:45:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BDDE912EF; Mon, 22 Apr 2002 17:45:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C708912C9 for ; Mon, 22 Apr 2002 17:45:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51E705DDC6; Mon, 22 Apr 2002 17:45:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 933C25DDC7 for ; Mon, 22 Apr 2002 17:45:42 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLjVw10683 for ; Tue, 23 Apr 2002 01:45:31 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id A540D8512; Tue, 23 Apr 2002 01:45:29 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214529.A540D8512@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:45:29 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:48:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15447 for ; Mon, 22 Apr 2002 17:48:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0942A912A9; Mon, 22 Apr 2002 17:47:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD345912A7; Mon, 22 Apr 2002 17:47:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16665912A9 for ; Mon, 22 Apr 2002 17:47:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E825B5DDC6; Mon, 22 Apr 2002 17:47:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 233585DDC7 for ; Mon, 22 Apr 2002 17:47:22 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLl7w10800 for ; Tue, 23 Apr 2002 01:47:07 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 92B99826B; Tue, 23 Apr 2002 01:47:06 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214706.92B99826B@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:47:06 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:49:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15473 for ; Mon, 22 Apr 2002 17:49:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0D37912A7; Mon, 22 Apr 2002 17:48:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40AFC912AF; Mon, 22 Apr 2002 17:48:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11D90912A7 for ; Mon, 22 Apr 2002 17:48:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6F435DDC7; Mon, 22 Apr 2002 17:47:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 122D45DDC6 for ; Mon, 22 Apr 2002 17:47:45 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLlUw10820 for ; Tue, 23 Apr 2002 01:47:30 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 430B884BB; Tue, 23 Apr 2002 01:47:30 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214730.430B884BB@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:47:30 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:49:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15487 for ; Mon, 22 Apr 2002 17:49:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1AA7912D3; Mon, 22 Apr 2002 17:48:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B106912E7; Mon, 22 Apr 2002 17:48:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AC0D912C8 for ; Mon, 22 Apr 2002 17:48:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A46A45DE1C; Mon, 22 Apr 2002 17:48:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1F2425DDC6 for ; Mon, 22 Apr 2002 17:48:13 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLm3w10868 for ; Tue, 23 Apr 2002 01:48:03 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 1E44A8775; Tue, 23 Apr 2002 01:48:03 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214803.1E44A8775@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:48:03 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:49:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15511 for ; Mon, 22 Apr 2002 17:49:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79816912AA; Mon, 22 Apr 2002 17:49:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BD8A912AC; Mon, 22 Apr 2002 17:49:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49543912AA for ; Mon, 22 Apr 2002 17:49:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CC505DDC6; Mon, 22 Apr 2002 17:49:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id DB8F45DDC7 for ; Mon, 22 Apr 2002 17:49:11 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLn1w10921 for ; Tue, 23 Apr 2002 01:49:01 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 604368790; Tue, 23 Apr 2002 01:49:01 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214901.604368790@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:49:01 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:50:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15531 for ; Mon, 22 Apr 2002 17:50:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B26BF912AC; Mon, 22 Apr 2002 17:49:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83750912AD; Mon, 22 Apr 2002 17:49:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69E6D912AC for ; Mon, 22 Apr 2002 17:49:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C4AE5DDC7; Mon, 22 Apr 2002 17:49:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 7E7C25DDC6 for ; Mon, 22 Apr 2002 17:49:38 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLnQw10949 for ; Tue, 23 Apr 2002 01:49:26 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 928388795; Tue, 23 Apr 2002 01:49:25 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214925.928388795@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:49:25 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:50:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15549 for ; Mon, 22 Apr 2002 17:50:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF8CD912AD; Mon, 22 Apr 2002 17:50:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 887D4912AE; Mon, 22 Apr 2002 17:50:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A68DB912AD for ; Mon, 22 Apr 2002 17:49:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 831CB5DDC6; Mon, 22 Apr 2002 17:49:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1265E5DDD0 for ; Mon, 22 Apr 2002 17:49:46 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLnYw10961 for ; Tue, 23 Apr 2002 01:49:34 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 278928798; Tue, 23 Apr 2002 01:49:34 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422214934.278928798@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:49:34 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:50:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15589 for ; Mon, 22 Apr 2002 17:50:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9A6B912AE; Mon, 22 Apr 2002 17:50:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8164B912AF; Mon, 22 Apr 2002 17:50:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85A6A912AE for ; Mon, 22 Apr 2002 17:50:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64B045DDC7; Mon, 22 Apr 2002 17:50:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 540C75DDC6 for ; Mon, 22 Apr 2002 17:50:24 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLoEw11137 for ; Tue, 23 Apr 2002 01:50:14 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 004E887A3; Tue, 23 Apr 2002 01:50:13 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215013.004E887A3@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:50:13 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:51:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15607 for ; Mon, 22 Apr 2002 17:51:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7BE1C912DE; Mon, 22 Apr 2002 17:51:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22913912CA; Mon, 22 Apr 2002 17:51:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AE74912EA for ; Mon, 22 Apr 2002 17:51:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03C885DDC7; Mon, 22 Apr 2002 17:51:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 6EF645DDC6 for ; Mon, 22 Apr 2002 17:50:50 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLofw11183 for ; Tue, 23 Apr 2002 01:50:41 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 8C06784C8; Tue, 23 Apr 2002 01:50:40 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215040.8C06784C8@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:50:40 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:51:22 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15625 for ; Mon, 22 Apr 2002 17:51:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B5FA912C8; Mon, 22 Apr 2002 17:50:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DFDA912CA; Mon, 22 Apr 2002 17:50:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00ED0912C8 for ; Mon, 22 Apr 2002 17:50:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D42085DE32; Mon, 22 Apr 2002 17:50:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 3D7205DDC6 for ; Mon, 22 Apr 2002 17:50:38 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLoSw11164 for ; Tue, 23 Apr 2002 01:50:28 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id EF85F87A3; Tue, 23 Apr 2002 01:50:27 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215027.EF85F87A3@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:50:27 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:51:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15640 for ; Mon, 22 Apr 2002 17:51:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8D63912AF; Mon, 22 Apr 2002 17:51:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74941912CA; Mon, 22 Apr 2002 17:51:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 666AA912AF for ; Mon, 22 Apr 2002 17:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D3755DDC7; Mon, 22 Apr 2002 17:51:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 433625DDC6 for ; Mon, 22 Apr 2002 17:51:30 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLpMw11228 for ; Tue, 23 Apr 2002 01:51:22 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 7BBF787A0; Tue, 23 Apr 2002 01:51:22 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅ! Î ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215122.7BBF787A0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:51:22 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:52:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15703 for ; Mon, 22 Apr 2002 17:52:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9B96912E3; Mon, 22 Apr 2002 17:52:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A44D912E8; Mon, 22 Apr 2002 17:52:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 923B5912E3 for ; Mon, 22 Apr 2002 17:52:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7585E5DDD0; Mon, 22 Apr 2002 17:52:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1D0FA5DDC7 for ; Mon, 22 Apr 2002 17:52:00 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLpow11259 for ; Tue, 23 Apr 2002 01:51:50 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C545187A0; Tue, 23 Apr 2002 01:51:49 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215149.C545187A0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:51:49 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:52:30 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15728 for ; Mon, 22 Apr 2002 17:52:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05AD1912CA; Mon, 22 Apr 2002 17:51:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5542912E3; Mon, 22 Apr 2002 17:51:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4E68912CA for ; Mon, 22 Apr 2002 17:51:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A49325DE50; Mon, 22 Apr 2002 17:51:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E7B7F5DDC6 for ; Mon, 22 Apr 2002 17:51:41 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLpXw11240 for ; Tue, 23 Apr 2002 01:51:33 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 344C987B2; Tue, 23 Apr 2002 01:51:33 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215133.344C987B2@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:51:33 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:53:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15759 for ; Mon, 22 Apr 2002 17:53:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 076C7912E8; Mon, 22 Apr 2002 17:52:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0B90912E9; Mon, 22 Apr 2002 17:52:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B13C912E8 for ; Mon, 22 Apr 2002 17:52:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 464395DDC7; Mon, 22 Apr 2002 17:52:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 8CBA75DDC6 for ; Mon, 22 Apr 2002 17:52:41 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLqWw11334 for ; Tue, 23 Apr 2002 01:52:32 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id AFC9587C0; Tue, 23 Apr 2002 01:52:31 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215231.AFC9587C0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:52:31 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:53:16 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15771 for ; Mon, 22 Apr 2002 17:53:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FFA5912E7; Mon, 22 Apr 2002 17:52:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49ACC912E8; Mon, 22 Apr 2002 17:52:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C9F0912E7 for ; Mon, 22 Apr 2002 17:52:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 883F75DDC7; Mon, 22 Apr 2002 17:52:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 7DC015DDD0 for ; Mon, 22 Apr 2002 17:52:33 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLqLw11316 for ; Tue, 23 Apr 2002 01:52:21 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 39A8E87B8; Tue, 23 Apr 2002 01:52:21 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖ! Å!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215221.39A8E87B8@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:52:21 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:53:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15791 for ; Mon, 22 Apr 2002 17:53:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA8F7912E9; Mon, 22 Apr 2002 17:53:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2500912EA; Mon, 22 Apr 2002 17:53:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 410DF912E9 for ; Mon, 22 Apr 2002 17:53:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 216745DDD0; Mon, 22 Apr 2002 17:53:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 2B7445DDC7 for ; Mon, 22 Apr 2002 17:53:07 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLquw11370 for ; Tue, 23 Apr 2002 01:52:56 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 954D68212; Tue, 23 Apr 2002 01:52:55 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215255.954D68212@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:52:55 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:54:32 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15834 for ; Mon, 22 Apr 2002 17:54:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6BB5912EA; Mon, 22 Apr 2002 17:53:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73A4B912EC; Mon, 22 Apr 2002 17:53:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55976912EA for ; Mon, 22 Apr 2002 17:53:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 348355DDC7; Mon, 22 Apr 2002 17:53:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id D53C85DDC6 for ; Mon, 22 Apr 2002 17:53:43 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLrXw11426 for ; Tue, 23 Apr 2002 01:53:33 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id C39D987CC; Tue, 23 Apr 2002 01:53:32 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕ! Ö!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215332.C39D987CC@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:53:32 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:54:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15832 for ; Mon, 22 Apr 2002 17:54:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 517CA912EE; Mon, 22 Apr 2002 17:54:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3B37912EF; Mon, 22 Apr 2002 17:54:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88FB7912EC for ; Mon, 22 Apr 2002 17:54:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BF435DDC7; Mon, 22 Apr 2002 17:54:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id D13805DDD0 for ; Mon, 22 Apr 2002 17:53:51 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLrfw11440 for ; Tue, 23 Apr 2002 01:53:41 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id F2C1287C0; Tue, 23 Apr 2002 01:53:40 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215340.F2C1287C0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:53:40 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:54:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15861 for ; Mon, 22 Apr 2002 17:54:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 09B06912EC; Mon, 22 Apr 2002 17:54:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5315912EB; Mon, 22 Apr 2002 17:54:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A79A6912F0 for ; Mon, 22 Apr 2002 17:54:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 171BA5DDD0; Mon, 22 Apr 2002 17:54:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 0E8EC5DDC6 for ; Mon, 22 Apr 2002 17:54:15 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLs0w11470 for ; Tue, 23 Apr 2002 01:54:00 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 7AA278564; Tue, 23 Apr 2002 01:54:00 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215400.7AA278564@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:54:00 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:55:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15916 for ; Mon, 22 Apr 2002 17:55:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02B90912EF; Mon, 22 Apr 2002 17:55:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4427912F0; Mon, 22 Apr 2002 17:55:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90EEC912EF for ; Mon, 22 Apr 2002 17:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79E505DDC6; Mon, 22 Apr 2002 17:55:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 32B285DDD0 for ; Mon, 22 Apr 2002 17:55:08 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLsuw11533 for ; Tue, 23 Apr 2002 01:54:56 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5959F83A6; Tue, 23 Apr 2002 01:54:55 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215455.5959F83A6@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:54:55 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:55:43 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15928 for ; Mon, 22 Apr 2002 17:55:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB9C3912EB; Mon, 22 Apr 2002 17:55:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79193912EF; Mon, 22 Apr 2002 17:55:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71480912EB for ; Mon, 22 Apr 2002 17:55:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A66E5DDC7; Mon, 22 Apr 2002 17:55:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id B20785DDC6 for ; Mon, 22 Apr 2002 17:54:59 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLslw11523 for ; Tue, 23 Apr 2002 01:54:47 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id CEECD87E0; Tue, 23 Apr 2002 01:54:46 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒ! Õ!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215446.CEECD87E0@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:54:46 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:56:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15950 for ; Mon, 22 Apr 2002 17:56:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B81F3912F1; Mon, 22 Apr 2002 17:55:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BC29912F0; Mon, 22 Apr 2002 17:55:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77B51912F2 for ; Mon, 22 Apr 2002 17:55:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CF325DDC7; Mon, 22 Apr 2002 17:55:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id BC1D95DDC6 for ; Mon, 22 Apr 2002 17:55:30 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLtHw11566 for ; Tue, 23 Apr 2002 01:55:17 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 0C3C187DD; Tue, 23 Apr 2002 01:55:16 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215516.0C3C187DD@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:55:16 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:56:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15999 for ; Mon, 22 Apr 2002 17:56:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E44D912F0; Mon, 22 Apr 2002 17:56:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01B8C912F2; Mon, 22 Apr 2002 17:56:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04767912F0 for ; Mon, 22 Apr 2002 17:56:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0E195DDC7; Mon, 22 Apr 2002 17:56:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 34DC85DDC6 for ; Mon, 22 Apr 2002 17:56:25 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLu9w11604 for ; Tue, 23 Apr 2002 01:56:09 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 648FD87C5; Tue, 23 Apr 2002 01:56:08 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁ! Ò!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215608.648FD87C5@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:56:08 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:57:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16019 for ; Mon, 22 Apr 2002 17:57:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5A2F912F2; Mon, 22 Apr 2002 17:57:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B3F0912F3; Mon, 22 Apr 2002 17:57:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B8CA912F2 for ; Mon, 22 Apr 2002 17:57:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74A085DDC7; Mon, 22 Apr 2002 17:57:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 814515DDC6 for ; Mon, 22 Apr 2002 17:56:55 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLuiw11645 for ; Tue, 23 Apr 2002 01:56:44 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id BA82F84FC; Tue, 23 Apr 2002 01:56:43 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215643.BA82F84FC@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:56:43 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:58:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16040 for ; Mon, 22 Apr 2002 17:58:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95BDF912F3; Mon, 22 Apr 2002 17:57:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46B65912F5; Mon, 22 Apr 2002 17:57:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EFEA912F3 for ; Mon, 22 Apr 2002 17:57:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25CF35DDC7; Mon, 22 Apr 2002 17:57:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 8915F5DDC6 for ; Mon, 22 Apr 2002 17:57:33 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLv8w11675 for ; Tue, 23 Apr 2002 01:57:08 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id A919483EF; Tue, 23 Apr 2002 01:57:07 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215707.A919483EF@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:57:07 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:59:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16057 for ; Mon, 22 Apr 2002 17:59:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2C74912F4; Mon, 22 Apr 2002 17:58:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AC35912F9; Mon, 22 Apr 2002 17:58:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 721D5912F4 for ; Mon, 22 Apr 2002 17:58:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 460965DE56; Mon, 22 Apr 2002 17:58:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id EA9155DDC6 for ; Mon, 22 Apr 2002 17:58:32 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLwFw11735 for ; Tue, 23 Apr 2002 01:58:15 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id B8C098801; Tue, 23 Apr 2002 01:58:14 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎ! Á!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215814.B8C098801@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:58:14 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 17:59:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16070 for ; Mon, 22 Apr 2002 17:59:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2685912F5; Mon, 22 Apr 2002 17:59:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A403F912F6; Mon, 22 Apr 2002 17:59:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9614B912F5 for ; Mon, 22 Apr 2002 17:59:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F1CC5DDC7; Mon, 22 Apr 2002 17:59:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 878F35DDC6 for ; Mon, 22 Apr 2002 17:59:04 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLwpw11768 for ; Tue, 23 Apr 2002 01:58:51 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 8C4AA8805; Tue, 23 Apr 2002 01:58:50 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422215850.8C4AA8805@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:58:50 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:01:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16186 for ; Mon, 22 Apr 2002 18:01:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2843912F6; Mon, 22 Apr 2002 18:00:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7627F912F8; Mon, 22 Apr 2002 18:00:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8ABB5912F6 for ; Mon, 22 Apr 2002 18:00:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FAE65DDC7; Mon, 22 Apr 2002 18:00:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 5AFF95DDC6 for ; Mon, 22 Apr 2002 18:00:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MM0Jw12026 for ; Tue, 23 Apr 2002 02:00:19 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6CF0A858A; Tue, 23 Apr 2002 02:00:18 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422220018.6CF0A858A@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:00:18 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:05:33 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16308 for ; Mon, 22 Apr 2002 18:05:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 134BD912FF; Mon, 22 Apr 2002 18:02:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C12D191301; Mon, 22 Apr 2002 18:02:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2B7191304 for ; Mon, 22 Apr 2002 18:01:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E03C5DDC7; Mon, 22 Apr 2002 18:01:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 1D69F5DDC6 for ; Mon, 22 Apr 2002 18:01:44 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MM1Yw12162 for ; Tue, 23 Apr 2002 02:01:34 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id ECB5D8523; Tue, 23 Apr 2002 02:01:32 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂ! Î!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422220132.ECB5D8523@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:01:32 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:08:24 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16347 for ; Mon, 22 Apr 2002 18:08:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 217819130A; Mon, 22 Apr 2002 18:03:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 992A391306; Mon, 22 Apr 2002 18:03:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CC1891301 for ; Mon, 22 Apr 2002 18:03:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1D665DDC7; Mon, 22 Apr 2002 18:03:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 51C0F5DDC6 for ; Mon, 22 Apr 2002 18:02:55 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MM2dw12221 for ; Tue, 23 Apr 2002 02:02:39 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 3A842880D; Tue, 23 Apr 2002 02:02:38 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422220238.3A842880D@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:02:38 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:08:36 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16359 for ; Mon, 22 Apr 2002 18:08:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B92679131D; Mon, 22 Apr 2002 18:06:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8050D91321; Mon, 22 Apr 2002 18:06:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 880FE9131D for ; Mon, 22 Apr 2002 18:06:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E8FA5DDC7; Mon, 22 Apr 2002 18:06:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id C59395DDC6 for ; Mon, 22 Apr 2002 18:05:47 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MM5bw12413 for ; Tue, 23 Apr 2002 02:05:37 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 783C98358; Tue, 23 Apr 2002 02:05:35 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422220535.783C98358@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:05:35 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:12:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16472 for ; Mon, 22 Apr 2002 18:12:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB9BF912F7; Mon, 22 Apr 2002 18:11:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD214912F9; Mon, 22 Apr 2002 18:11:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1923912F7 for ; Mon, 22 Apr 2002 18:11:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A8AF85DDC7; Mon, 22 Apr 2002 18:11:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 23C935DDC6 for ; Mon, 22 Apr 2002 18:11:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MMBNw12875 for ; Tue, 23 Apr 2002 02:11:23 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 6E68988E7; Tue, 23 Apr 2002 02:11:22 +0400 (MSD) To: From: "Mark Jones" Subject: RE: [AAA-WG]: Result codes in vendor specific applications(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ï! Â!(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422221122.6E68988E7@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:11:22 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ mjones@bridgewatersystems.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:16:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16585 for ; Mon, 22 Apr 2002 18:16:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5888912F9; Mon, 22 Apr 2002 18:15:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93064912FB; Mon, 22 Apr 2002 18:15:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76E93912F9 for ; Mon, 22 Apr 2002 18:15:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5DA805DDC7; Mon, 22 Apr 2002 18:15:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 28F985DDC6 for ; Mon, 22 Apr 2002 18:15:40 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3MMFdi28858; Mon, 22 Apr 2002 17:15:39 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3MMFdr14170; Mon, 22 Apr 2002 17:15:39 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA29697; Mon, 22 Apr 2002 17:15:39 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA26805; Mon, 22 Apr 2002 17:15:38 -0500 (CDT) Message-ID: <3CC48AC9.F015E7C2@ericsson.com> Date: Mon, 22 Apr 2002 15:12:25 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob and Johan, Bob Kopacz wrote: > Hi Johan, > > > From: Johan Johansson [johanj@ipunplugged.com] > > Sent: Monday, April 15, 2002 5:33 AM > > To: Bob Kopacz > > Cc: Tony Johansson; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > > > > Bob Kopacz wrote: > > > > >1. Johan's comment (paraphrased as I understand it) that what is really > > >needed for issue#301 is for the AAAH to know the identity of the > > >destination AAAF hosting the foreign HA. Although by requiring a fixed > > >AAAH over the life of a MN's session, the AAAH can (with some effort) come > > >up with the AAAF's identity, why not instead have the MN cache the > > >destination AAAF's identity instead of the AAAH's identity? This > > >eliminates the seemingly unnecessary restriction, and single point of > > >failure, of a fixed AAAH. > > > > Yes, this was my still unanswered question. > > > > It seems to me that if the HA's AAAF's Identity was added as another > subtype for the AAA NAI extension, and if this information was returned > to the MN instead of (or in addition to) the AAAH's identity, then this > would meet the needs of issues #299 and #301. So are you saying that we don't meet the needs for issue #299 and #301 without the AAAF's Identity?! > > > Matter of fact, feeding the Destination-AAAF's identity to the MN might > be a good idea, anyway, as this would allow the session to continue if > the AAAH became unavailable. I really don't see why this would make it any easier?!. Is it that bad for the MN to re- authenticate its self if the AAAH becomes unavailable? Thus, the AAAF notice that the AAAH is unavailable (either directly by itself or by a returned result code from an Diameter agent on the path), the AAAF will return an error back to the MN via the FA and the MN will register again without the AAAH NAI. How can this be better handled by always forwarding the AMR to the same AAAF?! Furthermore, what should a FA do when receiving a AAAF Identity from a foreign network in AAA NAI from the MN? Thus, when the a MN moves from one network to a new network the MN would have the AAAF stored from the previous network. So should the FA issue the AMR to foreign AAAF ?!?! > > > > >On the other hand, a single AAAH does have some modest virtues: > > >[a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new > > >SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't > > >change, the HA doesn't have to clear the session with the old AAAH when > > >a new AAAH comes on board; [c] does session/policy/resource management > > >become easier with a fixed AAAH? > > > > > > > I agree with all of the above but I strongly disagree that it is > > mandatory. They should all be perfectly allowable optimizations but > > mandating them is unnecessary, removes an interesting degree of freedom > > and most importantly forces external mechanisms to be used where none is > > needed. > > I don't disagree with you here either. It is a judgement call But nothing is really mandatory. Please, help me to understand where you see the real problem here. Regards, /Tony From owner-aaa-wg@merit.edu Mon Apr 22 18:16:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16605 for ; Mon, 22 Apr 2002 18:16:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32AA5912FA; Mon, 22 Apr 2002 18:16:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5D08912FC; Mon, 22 Apr 2002 18:16:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C78B5912FA for ; Mon, 22 Apr 2002 18:16:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A88CC5DE32; Mon, 22 Apr 2002 18:16:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id D7EAD5DDC6 for ; Mon, 22 Apr 2002 18:16:14 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MMG7w13172 for ; Tue, 23 Apr 2002 02:16:07 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 5C31C858F; Tue, 23 Apr 2002 02:16:06 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422221606.5C31C858F@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:16:06 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:17:58 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16675 for ; Mon, 22 Apr 2002 18:17:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAD31912FC; Mon, 22 Apr 2002 18:16:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BF1991303; Mon, 22 Apr 2002 18:16:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C089B912FC for ; Mon, 22 Apr 2002 18:16:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A09315DE32; Mon, 22 Apr 2002 18:16:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id B88F05DDC6 for ; Mon, 22 Apr 2002 18:16:34 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MMGOw13195 for ; Tue, 23 Apr 2002 02:16:24 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id DD9608938; Tue, 23 Apr 2002 02:16:23 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422221623.DD9608938@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:16:23 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:26:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14078 for ; Mon, 22 Apr 2002 17:26:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE3CE91279; Mon, 22 Apr 2002 17:26:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC08B9127B; Mon, 22 Apr 2002 17:26:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F38991279 for ; Mon, 22 Apr 2002 17:25:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 729595DDC6; Mon, 22 Apr 2002 17:25:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id E53C25DD8D for ; Mon, 22 Apr 2002 17:25:47 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MLPew08831 for ; Tue, 23 Apr 2002 01:25:40 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id E42478408; Tue, 23 Apr 2002 01:25:38 +0400 (MSD) To: "aaa-wg@merit.edu" From: "David Frascone \"Mark Jones\"" Subject: [mjones@bridgewatersystems.com: RE: [AAA-WG]: Result codes in vendor specific applications(????????? ?????!)](ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422212538.E42478408@rts.nio1.loniis> Date: Tue, 23 Apr 2002 01:25:38 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:32:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16849 for ; Mon, 22 Apr 2002 18:32:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A85CF912FB; Mon, 22 Apr 2002 18:32:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BFFD912FD; Mon, 22 Apr 2002 18:32:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B21E7912FB for ; Mon, 22 Apr 2002 18:32:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 973465DDD0; Mon, 22 Apr 2002 18:32:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 692BE5DDC6 for ; Mon, 22 Apr 2002 18:32:13 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MMW1w14268 for ; Tue, 23 Apr 2002 02:32:01 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 693178940; Tue, 23 Apr 2002 02:32:01 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422223201.693178940@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:32:01 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 18:59:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17345 for ; Mon, 22 Apr 2002 18:59:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B3D0491211; Mon, 22 Apr 2002 18:59:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85D76912FD; Mon, 22 Apr 2002 18:59:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A00F691211 for ; Mon, 22 Apr 2002 18:59:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 871C95DDD0; Mon, 22 Apr 2002 18:59:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 87F325DDC6 for ; Mon, 22 Apr 2002 18:59:27 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MMxFw16136 for ; Tue, 23 Apr 2002 02:59:15 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 053348B8C; Tue, 23 Apr 2002 02:59:15 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422225915.053348B8C@rts.nio1.loniis> Date: Tue, 23 Apr 2002 02:59:15 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 19:48:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18371 for ; Mon, 22 Apr 2002 19:48:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5402491216; Mon, 22 Apr 2002 19:48:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C271912FD; Mon, 22 Apr 2002 19:48:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C31891216 for ; Mon, 22 Apr 2002 19:48:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 130525DDE8; Mon, 22 Apr 2002 19:48:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 324825DDBD for ; Mon, 22 Apr 2002 19:48:04 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3MNlmw19939 for ; Tue, 23 Apr 2002 03:47:48 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 9C5FA8279; Tue, 23 Apr 2002 03:47:46 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020422234746.9C5FA8279@rts.nio1.loniis> Date: Tue, 23 Apr 2002 03:47:46 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 21:39:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21119 for ; Mon, 22 Apr 2002 21:39:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A26CF912FD; Mon, 22 Apr 2002 21:39:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DE9F912FE; Mon, 22 Apr 2002 21:39:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 785BD912FD for ; Mon, 22 Apr 2002 21:39:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56CF95DE4A; Mon, 22 Apr 2002 21:39:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id EB7015DDBD for ; Mon, 22 Apr 2002 21:39:31 -0400 (EDT) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g3N1dIw29646 for ; Tue, 23 Apr 2002 05:39:18 +0400 (MSD) Received: by rts.nio1.loniis (Postfix, from userid 1054) id 4136087CE; Tue, 23 Apr 2002 05:39:16 +0400 (MSD) To: "aaa-wg@merit.edu" From: David Frascone Subject: [AAA-WG]: Re: =?unknown-8bit?Q?=5Bmjones=40bridgewat?=(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!)(ïÂÎÁÒÕÖÅÎ ×ÉÒÕÓ!) Content-Type: text/plain; charset=koi8-r Message-Id: <20020423013916.4136087CE@rts.nio1.loniis> Date: Tue, 23 Apr 2002 05:39:16 +0400 (MSD) Sender: owner-aaa-wg@merit.edu Precedence: bulk äÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÂÙÌÏ ÚÁÄÅÒÖÁÎÏ ÎÁ ÐÏÞÔÏ×ÏÍ ÓÅÒ×ÅÒÅ, ÔÁË ËÁË ×ÏÚÍÏÖÎÏ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ. óÏÏÂÝÅÎÉÅ ÏÔÐÒÁ×ÌÅÎÏ Ó ÁÄÒÅÓÁ dave@frascone.com ÎÁ ÁÄÒÅÓ aaa-wg@merit.edu. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÄÁÎÎÏÅ ÓÏÏÂÝÅÎÉÅ ÎÅ Ñ×ÌÑÅÔÓÑ ÉÎÆÉÃÉÒÏ×ÁÎÎÙÍ ÉÌÉ ÏÎÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÐÏ ËÁËÉÍ ÌÉÂÏ ÄÒÕÇÉÍ ÐÒÉÞÉÎÁÍ, ÔÏ ÷ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÂÒÁÔÉÔØÓÑ Ë ×ÁÛÅÍÕ óÅÔÅ×ÏÍÕ áÄÍÉÎÉÓÔÒÁÔÏÒÕ. From owner-aaa-wg@merit.edu Mon Apr 22 22:40:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23006 for ; Mon, 22 Apr 2002 22:40:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 380F591218; Mon, 22 Apr 2002 22:40:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 061609121B; Mon, 22 Apr 2002 22:40:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 100C391218 for ; Mon, 22 Apr 2002 22:40:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E106A5DE0E; Mon, 22 Apr 2002 22:40:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C89225DDBC for ; Mon, 22 Apr 2002 22:40:23 -0400 (EDT) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id 3A3C079; Mon, 22 Apr 2002 22:40:23 -0400 (EDT) Message-ID: <000f01c1ea70$0d274a40$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Tony Johansson" Cc: "Johan Johansson" , References: <3CC48AC9.F015E7C2@ericsson.com> Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Mon, 22 Apr 2002 22:39:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, In responding to Johan, I seem to have created more confusion. > From: "Tony Johansson" > To: "Bob Kopacz" > Cc: "Johan Johansson" ; > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > Date: Monday, April 22, 2002 6:16 PM > > Hi Bob and Johan, > > Bob Kopacz wrote: > > > Hi Johan, > > > > > From: Johan Johansson [johanj@ipunplugged.com] > > > Sent: Monday, April 15, 2002 5:33 AM > > > To: Bob Kopacz > > > Cc: Tony Johansson; aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > > > > > > Bob Kopacz wrote: > > > > > > >1. Johan's comment (paraphrased as I understand it) that what is really > > > >needed for issue#301 is for the AAAH to know the identity of the > > > >destination AAAF hosting the foreign HA. Although by requiring a fixed > > > >AAAH over the life of a MN's session, the AAAH can (with some effort) come > > > >up with the AAAF's identity, why not instead have the MN cache the > > > >destination AAAF's identity instead of the AAAH's identity? This > > > >eliminates the seemingly unnecessary restriction, and single point of > > > >failure, of a fixed AAAH. > > > > > > Yes, this was my still unanswered question. > > > > > > > It seems to me that if the HA's AAAF's Identity was added as another > > subtype for the AAA NAI extension, and if this information was returned > > to the MN instead of (or in addition to) the AAAH's identity, then this > > would meet the needs of issues #299 and #301. > > So are you saying that we don't meet the needs for issue #299 and #301 without > the AAAF's Identity?! No, not at all. What I wasn't saying very well was that, it seems to me, the needs of issues #299 and #301 can be met by having the MN cache either: [a] The HA's identity and the AAAH's identity, or [b] The HA's identity and the destination AAAF's identity (i.e. the AAAF hosting the HA). We know option [a] above will work; that is what you sent out as proposed text. It seems that option [b] would also work. It satifies issue#299 (handoffs) because the HA's identity is provided, so whatever AAAH handles the AMR, this AAAH can route the HAR to the HA. It satisfies issue#301 (securing session keys) because, whatever AAAH receives the AMR, this AAAH knows the identity of the AAAF hosting the HA, in case the AAAH wants to set up a DSA with the destination-AAAF for the purpose of securing session keys. > > > > > > Matter of fact, feeding the Destination-AAAF's identity to the MN might > > be a good idea, anyway, as this would allow the session to continue if > > the AAAH became unavailable. > > I really don't see why this would make it any easier?!. I meant that, should the original AAAH become unavailable, a new AAAH could know the identity of the Destination-AAAF upon receiving the AMR, in case the new AAAH wanted to set up a DSA with the Destination-AAAF for the purpose of security session keys. > Is it that bad for the MN to re- authenticate its self if the AAAH becomes > unavailable? Thus, the AAAF notice that the AAAH is unavailable (either directly > by itself or by a returned result code from an Diameter agent on the path), the > AAAF will return an error back to the MN via the FA and the MN will register > again without the AAAH NAI. How can this be better handled by always forwarding > the AMR to the same AAAF?! > > Furthermore, what should a FA do when receiving a AAAF Identity from a foreign > network in AAA NAI from the MN? Thus, when the a MN moves from one network to a > new network the MN would have the AAAF stored from the previous network. So > should the FA issue the AMR to foreign AAAF ?!?! > Goodness, no. > > > > > > > >On the other hand, a single AAAH does have some modest virtues: > > > >[a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new > > > >SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't > > > >change, the HA doesn't have to clear the session with the old AAAH when > > > >a new AAAH comes on board; [c] does session/policy/resource management > > > >become easier with a fixed AAAH? > > > > > > > > > > I agree with all of the above but I strongly disagree that it is > > > mandatory. They should all be perfectly allowable optimizations but > > > mandating them is unnecessary, removes an interesting degree of freedom > > > and most importantly forces external mechanisms to be used where none is > > > needed. > > > > I don't disagree with you here either. It is a judgement call > > But nothing is really mandatory. Please, help me to understand where you see the > real problem here. I don't have a problem with your proposed text at all, Tony. I was saying that option [b] also appears to work. Option [a] has some pros and cons. It seemed like Johan was saying that option [b] also works, and I was responding that it seems to me that is true. > Regards, > > /Tony > From owner-aaa-wg@merit.edu Tue Apr 23 02:32:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07593 for ; Tue, 23 Apr 2002 02:32:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1564A91209; Tue, 23 Apr 2002 02:32:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C61A691258; Tue, 23 Apr 2002 02:32:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7A3691209 for ; Tue, 23 Apr 2002 02:32:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89E515DDFF; Tue, 23 Apr 2002 02:32:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C3EF85DDF5 for ; Tue, 23 Apr 2002 02:32:23 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3N6ZWgL009160; Tue, 23 Apr 2002 08:35:33 +0200 From: "Fredrik Johansson" To: "Bob Kopacz" , "Tony Johansson" Cc: "Johan Johansson" , Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Tue, 23 Apr 2002 08:32:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000f01c1ea70$0d274a40$f6512844@sanarb01.mi.comcast.net> X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, So if I have understood it correctly, the proposal is that if you receive the AAAF identity in the AMR you can set up an end-to-end security association with the AAAF in order to distribute keys? So what if we add the AAAF identity to the aaa-nai draft and state that every time it is received by the HA it has to be sent in the registration reply if sent via the AAA infrastructure. Furthermore we say that when a MN receives any of the AAA NAI subtypes it must include it in future registration request where the AAA may be invoked. We then make it a SHOULD for the FA to include the AAAH identity in the AMR and a MUST to include the other subtypes. Now it's up to the FA to decide if it would like to take the "optimised" way and send the AMR to the same AAAH as before (and later do a failover if it's down) or if it would like to just send it to the AAAH realm. Either way, the AAAH can reach the HA and if it's a new AAAH it can still set up an end-to-end security association with the AAAF that handles the HA if allocated in another foreign network. Have I understood everything correctly? /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Bob Kopacz >Sent: den 23 april 2002 04:39 >To: Tony Johansson >Cc: Johan Johansson; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 > > >Hi Tony, > >In responding to Johan, I seem to have created more confusion. > >> From: "Tony Johansson" >> To: "Bob Kopacz" >> Cc: "Johan Johansson" ; >> Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 >> Date: Monday, April 22, 2002 6:16 PM >> >> Hi Bob and Johan, >> >> Bob Kopacz wrote: >> >> > Hi Johan, >> > >> > > From: Johan Johansson [johanj@ipunplugged.com] >> > > Sent: Monday, April 15, 2002 5:33 AM >> > > To: Bob Kopacz >> > > Cc: Tony Johansson; aaa-wg@merit.edu >> > > Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 >> > > >> > > Bob Kopacz wrote: >> > > >> > > >1. Johan's comment (paraphrased as I understand it) that >what is really >> > > >needed for issue#301 is for the AAAH to know the identity of the >> > > >destination AAAF hosting the foreign HA. Although by >requiring a fixed >> > > >AAAH over the life of a MN's session, the AAAH can (with >some effort) come >> > > >up with the AAAF's identity, why not instead have the MN cache the >> > > >destination AAAF's identity instead of the AAAH's identity? This >> > > >eliminates the seemingly unnecessary restriction, and >single point of >> > > >failure, of a fixed AAAH. >> > > >> > > Yes, this was my still unanswered question. >> > > >> > >> > It seems to me that if the HA's AAAF's Identity was added as another >> > subtype for the AAA NAI extension, and if this information was returned >> > to the MN instead of (or in addition to) the AAAH's identity, then this >> > would meet the needs of issues #299 and #301. >> >> So are you saying that we don't meet the needs for issue #299 >and #301 without >> the AAAF's Identity?! > >No, not at all. What I wasn't saying very well was that, it seems to >me, the needs of issues #299 and #301 can be met by having >the MN cache either: >[a] The HA's identity and the AAAH's identity, or >[b] The HA's identity and the destination AAAF's identity (i.e. the AAAF >hosting the HA). > >We know option [a] above will work; that is what you sent out as proposed >text. > >It seems that option [b] would also work. It satifies issue#299 >(handoffs) because the HA's identity is provided, so whatever AAAH >handles the AMR, this AAAH can route the HAR to the HA. >It satisfies issue#301 (securing session keys) because, whatever AAAH >receives the AMR, this AAAH knows the identity of the AAAF hosting the >HA, in case the AAAH wants to set up a DSA with the destination-AAAF >for the purpose of securing session keys. > >> > >> > >> > Matter of fact, feeding the Destination-AAAF's identity to the MN might >> > be a good idea, anyway, as this would allow the session to continue if >> > the AAAH became unavailable. >> >> I really don't see why this would make it any easier?!. > >I meant that, should the original AAAH become unavailable, a new AAAH >could know the identity of the Destination-AAAF upon receiving the >AMR, in case the new AAAH wanted to set up a DSA with the >Destination-AAAF for the purpose of security session keys. > >> Is it that bad for the MN to re- authenticate its self if the >AAAH becomes >> unavailable? Thus, the AAAF notice that the AAAH is unavailable >(either directly >> by itself or by a returned result code from an Diameter agent on >the path), the >> AAAF will return an error back to the MN via the FA and the MN >will register >> again without the AAAH NAI. How can this be better handled by >always forwarding >> the AMR to the same AAAF?! >> >> Furthermore, what should a FA do when receiving a AAAF Identity >from a foreign >> network in AAA NAI from the MN? Thus, when the a MN moves from >one network to a >> new network the MN would have the AAAF stored from the previous >network. So >> should the FA issue the AMR to foreign AAAF ?!?! >> > >Goodness, no. > >> > >> > >> > > >On the other hand, a single AAAH does have some modest virtues: >> > > >[a] Once an SA is set up between the AAAH and the HA (or >HA's AAAF), new >> > > >SAs needn't be set up due to an AAAH change; [b] Since the >AAAH doesn't >> > > >change, the HA doesn't have to clear the session with the >old AAAH when >> > > >a new AAAH comes on board; [c] does session/policy/resource >management >> > > >become easier with a fixed AAAH? >> > > > >> > > >> > > I agree with all of the above but I strongly disagree that it is >> > > mandatory. They should all be perfectly allowable optimizations but >> > > mandating them is unnecessary, removes an interesting degree >of freedom >> > > and most importantly forces external mechanisms to be used >where none is >> > > needed. >> > >> > I don't disagree with you here either. It is a judgement call >> >> But nothing is really mandatory. Please, help me to understand >where you see the >> real problem here. > >I don't have a problem with your proposed text at all, Tony. I was >saying that option [b] also appears to work. Option [a] has some pros >and cons. It seemed like Johan was saying that option [b] also works, >and I was responding that it seems to me that is true. > >> Regards, >> >> /Tony >> > From owner-aaa-wg@merit.edu Tue Apr 23 09:56:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17982 for ; Tue, 23 Apr 2002 09:56:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A36B4912B4; Tue, 23 Apr 2002 09:56:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77399912B5; Tue, 23 Apr 2002 09:56:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44901912B4 for ; Tue, 23 Apr 2002 09:56:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28AA55DE20; Tue, 23 Apr 2002 09:56:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by segue.merit.edu (Postfix) with ESMTP id 615AC5DE1A for ; Tue, 23 Apr 2002 09:56:41 -0400 (EDT) Received: from jobim (jobim [157.159.100.41]) by hugo.int-evry.fr (8.8.8/jtpda-5.3) with ESMTP id PAA13335 ; Tue, 23 Apr 2002 15:56:18 +0200 (MET DST) Date: Tue, 23 Apr 2002 15:56:28 +0200 (MET DST) From: julien Bournelle X-Sender: bournell@jobim Reply-To: julien.bournelle@int-evry.fr To: aaa-wg@merit.edu Cc: Julien.BOurnelle@int-evry.fr Subject: [AAA-WG]: Diameter Mobile IP question... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, I'm reading Mobile IP Application for Diameter and I am a little bit confused about the forwarding of AMR message. In Mobile IP App. document it is written : "upon receiving the AMR, the AAAF follows the procedure outlined in [DIAMBASE] to determine wether the AMR should be processed locally, or if it should be forwarded to another Diameter Server" In DIAMBASE there are two parts which give some informations about the procedures to follow when we receive a message: In part concerning Realm-Based Routing Table there are four possible actions : - LOCAL - RELAY - PROXY - REDIRECT So I guess that for an AMR message processed in AAAF it is RELAY or PROXY but I don't know which one. In part concerning Diameter Message Processing (p 67) it is written that the message must be processed in the following order: 1/ If message destined for the local host, procedures listed in 6.1.4 are followed 2/ If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in 6.1.5 are followed. This is Request Forwarding 3/ else 6.1.6 -> Request Routing So If my AAAF (realm mno.net) receives a message AMR with Dest-Realm xyz.com I am in case 3/ which points to 6.1.6 section. But If my local action for this realm is RELAY or PROXY, I must see section 6.1.8 (cf p 21). So I am a little bit confused. How do I choose if my AAAF is a RELAY or a PROXY ? Do I follow section 6.1.6 or 6.1.8 ? Maybe I haven't read enough the draft.. Regards, Julien.Bournelle@int-evry.fr From owner-aaa-wg@merit.edu Tue Apr 23 10:20:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18937 for ; Tue, 23 Apr 2002 10:20:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55059912B7; Tue, 23 Apr 2002 10:20:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDD43912BA; Tue, 23 Apr 2002 10:20:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3861912B7 for ; Tue, 23 Apr 2002 10:20:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF8C55DDF3; Tue, 23 Apr 2002 10:20:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id D51E75DDA6 for ; Tue, 23 Apr 2002 10:20:34 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g3NDP9a26802; Tue, 23 Apr 2002 15:25:10 +0200 Message-ID: <3CC56D79.4080909@ipunplugged.com> Date: Tue, 23 Apr 2002 16:19:37 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Fredrik Johansson Cc: Bob Kopacz , Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody. Comments are embedded at random intervals. Fredrik Johansson wrote: >All, > >So if I have understood it correctly, the proposal is that if you receive >the AAAF identity in the AMR you can set up an end-to-end security >association with the AAAF in order to distribute keys? > >So what if we add the AAAF identity to the aaa-nai draft and state that >every time it is received by the HA it has to be sent in the registration >reply if sent via the AAA infrastructure. Furthermore we say that when a MN >receives any of the AAA NAI subtypes it must include it in future >registration request where the AAA may be invoked. > >We then make it a SHOULD for the FA to include the AAAH identity in the AMR >and a MUST to include the other subtypes. > >Now it's up to the FA to decide if it would like to take the "optimised" way >and send the AMR to the same AAAH as before (and later do a failover if it's >down) or if it would like to just send it to the AAAH realm. Either way, the >AAAH can reach the HA and if it's a new AAAH it can still set up an >end-to-end security association with the AAAF that handles the HA if >allocated in another foreign network. > >Have I understood everything correctly? > No. It is infeasible to have the foreign network decide things which concern the home network. If we however demand that the MN always echoes back whatever GNAIs that it receives and that the FA converts all that it receives to Diameter-speak the HA can then decide the policy by choosing which extensions that it includes in the MIP-Reg-Replys that it sends. This seems to me to allow both ways of doing things while complicating neither. I am probably wrong though, so please point out my mistake. >>>>It seems to me that if the HA's AAAF's Identity was added as another >>>>subtype for the AAA NAI extension, and if this information was returned >>>>to the MN instead of (or in addition to) the AAAH's identity, then this >>>>would meet the needs of issues #299 and #301. >>>> >>>So are you saying that we don't meet the needs for issue #299 >>> >>and #301 without >> >>>the AAAF's Identity?! >>> >>No, not at all. What I wasn't saying very well was that, it seems to >>me, the needs of issues #299 and #301 can be met by having >>the MN cache either: >>[a] The HA's identity and the AAAH's identity, or >>[b] The HA's identity and the destination AAAF's identity (i.e. the AAAF >>hosting the HA). >> >>We know option [a] above will work; that is what you sent out as proposed >>text. >> >>It seems that option [b] would also work. It satifies issue#299 >>(handoffs) because the HA's identity is provided, so whatever AAAH >>handles the AMR, this AAAH can route the HAR to the HA. >>It satisfies issue#301 (securing session keys) because, whatever AAAH >>receives the AMR, this AAAH knows the identity of the AAAF hosting the >>HA, in case the AAAH wants to set up a DSA with the destination-AAAF >>for the purpose of securing session keys. >> [a] however *requires* a cache of HA-to-AAAF mappings to be maintained on the AAAH and if the AAAH fails there is no way another AAAH can figure out which AAAF controls the HA. Diameter failover as specified in the base will *not* work in this case since the information is quite simply lost. Unless you maintain the cache in a manner that makes it available to all your AAAHs of course. I personally think this is unattractive when there is such a simple alternative, but the procedures outlined above would allow it. >>>> >>>>Matter of fact, feeding the Destination-AAAF's identity to the MN might >>>>be a good idea, anyway, as this would allow the session to continue if >>>>the AAAH became unavailable. >>>> >>>I really don't see why this would make it any easier?!. >>> >>I meant that, should the original AAAH become unavailable, a new AAAH >>could know the identity of the Destination-AAAF upon receiving the >>AMR, in case the new AAAH wanted to set up a DSA with the >>Destination-AAAF for the purpose of security session keys. >> >>>Is it that bad for the MN to re- authenticate its self if the >>> >>AAAH becomes >> >>>unavailable? Thus, the AAAF notice that the AAAH is unavailable >>> >>(either directly >> >>>by itself or by a returned result code from an Diameter agent on >>> >>the path), the >> >>>AAAF will return an error back to the MN via the FA and the MN >>> >>will register >> >>>again without the AAAH NAI. How can this be better handled by >>> >>always forwarding >> >>>the AMR to the same AAAF?! >>> I think what Bob means is that unless you know the identity of the old AAAF you can not keep your HA and therefore it is game over for your session regardless of whether the MN reauthenticates itself or not. Please note that we are talking about the AAAF controlling the HA and not the one controlling the FA. j From owner-aaa-wg@merit.edu Tue Apr 23 16:45:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06246 for ; Tue, 23 Apr 2002 16:45:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 864D5912C0; Tue, 23 Apr 2002 16:44:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57E0C912C1; Tue, 23 Apr 2002 16:44:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 33A8D912C0 for ; Tue, 23 Apr 2002 16:44:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10CFC5DE28; Tue, 23 Apr 2002 16:44:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id AEAE65DE1A for ; Tue, 23 Apr 2002 16:44:52 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3NKipl14201; Tue, 23 Apr 2002 15:44:51 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3NKipp22295; Tue, 23 Apr 2002 15:44:51 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23214; Tue, 23 Apr 2002 15:44:50 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA16189; Tue, 23 Apr 2002 15:44:49 -0500 (CDT) Message-ID: <3CC5C701.9B55B6F0@ericsson.com> Date: Tue, 23 Apr 2002 13:41:37 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: Fredrik Johansson , Bob Kopacz , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: <3CC56D79.4080909@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Right now we have a proposal, based on the HA's NAI and the AAAH's NAI, which folks from both MIP-wg and AAA-wg seems to agree on. Sure, the proposad solution may be less optimal in some cases, however, the other proposal is also less optimal in other cases. Regardless of which AAA NAI you decide to specify, if it goes down you will have a problem. For example, adding the AAAF's NAI is also possible, however this is an attempt to optimize scenarios that uses CMS encryption - which may not even be used - and also what happens in the case the AAAF in unavailable? Thus, the AAAH receives an AMR with an included AAAF NAI and if the AAAF is down - in what way would this then be better solved then in the case that AAAH is down.... So, the point I'm trying to make here is that we have a solution (based on the AAAH NAI and the HA NAI), which I believe is good enough and that we have consensus for. If you really disagree with me here, please provide text to the spec that really shows why the AAAF is necessary (and not solely an optimization) and worth to delay the spec even more. Regards, /Tony Johan Johansson wrote: > Hi everybody. Comments are embedded at random intervals. > > Fredrik Johansson wrote: > > >All, > > > >So if I have understood it correctly, the proposal is that if you receive > >the AAAF identity in the AMR you can set up an end-to-end security > >association with the AAAF in order to distribute keys? > > > >So what if we add the AAAF identity to the aaa-nai draft and state that > >every time it is received by the HA it has to be sent in the registration > >reply if sent via the AAA infrastructure. Furthermore we say that when a MN > >receives any of the AAA NAI subtypes it must include it in future > >registration request where the AAA may be invoked. > > > >We then make it a SHOULD for the FA to include the AAAH identity in the AMR > >and a MUST to include the other subtypes. > > > >Now it's up to the FA to decide if it would like to take the "optimised" way > >and send the AMR to the same AAAH as before (and later do a failover if it's > >down) or if it would like to just send it to the AAAH realm. Either way, the > >AAAH can reach the HA and if it's a new AAAH it can still set up an > >end-to-end security association with the AAAF that handles the HA if > >allocated in another foreign network. > > > >Have I understood everything correctly? > > > > No. It is infeasible to have the foreign network decide things which > concern the home network. If we however demand that the MN always echoes > back whatever GNAIs that it receives and that the FA converts all that > it receives to Diameter-speak the HA can then decide the policy by > choosing which extensions that it includes in the MIP-Reg-Replys that it > sends. > > This seems to me to allow both ways of doing things while complicating > neither. I am probably wrong though, so please point out my mistake. > > >>>>It seems to me that if the HA's AAAF's Identity was added as another > >>>>subtype for the AAA NAI extension, and if this information was returned > >>>>to the MN instead of (or in addition to) the AAAH's identity, then this > >>>>would meet the needs of issues #299 and #301. > >>>> > >>>So are you saying that we don't meet the needs for issue #299 > >>> > >>and #301 without > >> > >>>the AAAF's Identity?! > >>> > >>No, not at all. What I wasn't saying very well was that, it seems to > >>me, the needs of issues #299 and #301 can be met by having > >>the MN cache either: > >>[a] The HA's identity and the AAAH's identity, or > >>[b] The HA's identity and the destination AAAF's identity (i.e. the AAAF > >>hosting the HA). > >> > >>We know option [a] above will work; that is what you sent out as proposed > >>text. > >> > >>It seems that option [b] would also work. It satifies issue#299 > >>(handoffs) because the HA's identity is provided, so whatever AAAH > >>handles the AMR, this AAAH can route the HAR to the HA. > >>It satisfies issue#301 (securing session keys) because, whatever AAAH > >>receives the AMR, this AAAH knows the identity of the AAAF hosting the > >>HA, in case the AAAH wants to set up a DSA with the destination-AAAF > >>for the purpose of securing session keys. > >> > > [a] however *requires* a cache of HA-to-AAAF mappings to be maintained > on the AAAH and if the AAAH fails there is no way another AAAH can > figure out which AAAF controls the HA. Diameter failover as specified in > the base will *not* work in this case since the information is quite > simply lost. Unless you maintain the cache in a manner that makes it > available to all your AAAHs of course. I personally think this is > unattractive when there is such a simple alternative, but the procedures > outlined above would allow it. > > >>>> > >>>>Matter of fact, feeding the Destination-AAAF's identity to the MN might > >>>>be a good idea, anyway, as this would allow the session to continue if > >>>>the AAAH became unavailable. > >>>> > >>>I really don't see why this would make it any easier?!. > >>> > >>I meant that, should the original AAAH become unavailable, a new AAAH > >>could know the identity of the Destination-AAAF upon receiving the > >>AMR, in case the new AAAH wanted to set up a DSA with the > >>Destination-AAAF for the purpose of security session keys. > >> > >>>Is it that bad for the MN to re- authenticate its self if the > >>> > >>AAAH becomes > >> > >>>unavailable? Thus, the AAAF notice that the AAAH is unavailable > >>> > >>(either directly > >> > >>>by itself or by a returned result code from an Diameter agent on > >>> > >>the path), the > >> > >>>AAAF will return an error back to the MN via the FA and the MN > >>> > >>will register > >> > >>>again without the AAAH NAI. How can this be better handled by > >>> > >>always forwarding > >> > >>>the AMR to the same AAAF?! > >>> > > I think what Bob means is that unless you know the identity of the old > AAAF you can not keep your HA and therefore it is game over for your > session regardless of whether the MN reauthenticates itself or not. > Please note that we are talking about the AAAF controlling the HA and > not the one controlling the FA. > > j From owner-aaa-wg@merit.edu Tue Apr 23 17:57:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07764 for ; Tue, 23 Apr 2002 17:57:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A42A91205; Tue, 23 Apr 2002 17:57:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC7DA912C1; Tue, 23 Apr 2002 17:57:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7F1091205 for ; Tue, 23 Apr 2002 17:57:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F72C5DE4C; Tue, 23 Apr 2002 17:57:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id C7F805DE28 for ; Tue, 23 Apr 2002 17:57:43 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020423215742.HREG9302.fep03-svc.swip.net@ipunplugged.com>; Tue, 23 Apr 2002 23:57:42 +0200 Message-ID: <3CC5D92A.2020904@ipunplugged.com> Date: Tue, 23 Apr 2002 23:59:06 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Johansson Cc: Fredrik Johansson , Bob Kopacz , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: <3CC56D79.4080909@ipunplugged.com> <3CC5C701.9B55B6F0@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'll compose a fuller response tomorrow. For now I just want to answer one thing. Tony Johansson wrote: >goes down you will have a problem. For example, adding the AAAF's NAI is also >possible, however this is an attempt to optimize scenarios that uses CMS >encryption - which may not even be used - and also what happens in the case the >AAAF in unavailable? Thus, the AAAH receives an AMR with an included AAAF NAI and >if the AAAF is down - in what way would this then be better solved then in the >case that AAAH is down.... > In your suggestion the session ends if the AAAH *or* the AAAF goes down. My suggestion has one point of failure less. j From owner-aaa-wg@merit.edu Wed Apr 24 03:20:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26389 for ; Wed, 24 Apr 2002 03:20:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E906791222; Wed, 24 Apr 2002 03:20:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90E3791228; Wed, 24 Apr 2002 03:20:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8850B91222 for ; Wed, 24 Apr 2002 03:19:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E0C25DE18; Wed, 24 Apr 2002 03:19:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 7D01C5DD93 for ; Wed, 24 Apr 2002 03:19:04 -0400 (EDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3O7MHgL004293; Wed, 24 Apr 2002 09:22:17 +0200 From: "Fredrik Johansson" To: "Johan Johansson" , "Tony Johansson" Cc: "Bob Kopacz" , Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Wed, 24 Apr 2002 09:19:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3CC5D92A.2020904@ipunplugged.com> Importance: Normal X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan, > >I'll compose a fuller response tomorrow. For now I just want to answer >one thing. > >Tony Johansson wrote: > >>goes down you will have a problem. For example, adding the AAAF's >NAI is also >>possible, however this is an attempt to optimize scenarios that uses CMS >>encryption - which may not even be used - and also what happens >in the case the >>AAAF in unavailable? Thus, the AAAH receives an AMR with an >included AAAF NAI and >>if the AAAF is down - in what way would this then be better >solved then in the >>case that AAAH is down.... >> >In your suggestion the session ends if the AAAH *or* the AAAF goes down. NO, the failover mechanism in diameter-base still makes it possible to change to another AAAH if the original one is down. The AMR still contains the HA's identity so it can be reached, what it may not know is the identity of the AAAF for a possible CVS transaction, but since we're not sure what/how CMS will work, I would prefer that we go with a solution that we know works, maybe not optimized in every sence, but it's at least simple. Others? /Fredrik >My suggestion has one point of failure less. > >j From owner-aaa-wg@merit.edu Wed Apr 24 03:58:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26849 for ; Wed, 24 Apr 2002 03:58:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CD9891228; Wed, 24 Apr 2002 03:57:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E9AB91233; Wed, 24 Apr 2002 03:57:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 424AD91228 for ; Wed, 24 Apr 2002 03:57:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 116225DE6F; Wed, 24 Apr 2002 03:57:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id 6CF0D5DE18 for ; Wed, 24 Apr 2002 03:57:48 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by relay.wineasy.se with ESMTP id g3O72VA20238; Wed, 24 Apr 2002 09:02:33 +0200 Message-ID: <3CC66547.3050905@ipunplugged.com> Date: Wed, 24 Apr 2002 09:56:55 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Fredrik Johansson Cc: Tony Johansson , Bob Kopacz , aaa-wg@merit.edu Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson wrote: >>In your suggestion the session ends if the AAAH *or* the AAAF goes down. >> > >NO, the failover mechanism in diameter-base still makes it possible to >change to another AAAH if the original one is down. The AMR still contains >the HA's identity so it can be reached, what it may not know is the identity >of the AAAF for a possible CVS transaction, but since we're not sure >what/how CMS will work, I would prefer that we go with a solution that we >know works, maybe not optimized in every sence, but it's at least simple. > >Others? > I don't know if I qualify as others, but... The reason I am involving CMS is that it is what issue #301 is about. Since it's about securing AAAH-generated keys I don't really see how it is possible to ignore CMS. I also fail to see the complication in "if you get a GNAI extension return it/forward it" compared to "maintain a cache of HA-to-AAAF mappings". It's also hard for me to understand how it might not work at least as well since it includes the other suggested solution as a special case. I have been arguing my case for several weeks now and only rarely received comments that discuss the technical nature of my proposal or that answer my critique of the other suggested solution. This is disappointing. I will try to deliver an alternative text during the day so that it at least exists. j From owner-aaa-wg@merit.edu Wed Apr 24 06:35:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28948 for ; Wed, 24 Apr 2002 06:35:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BC3691201; Wed, 24 Apr 2002 06:35:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC1BC91233; Wed, 24 Apr 2002 06:35:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF10B91201 for ; Wed, 24 Apr 2002 06:35:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 752855DD93; Wed, 24 Apr 2002 06:35:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 885425DE7A for ; Wed, 24 Apr 2002 06:35:18 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OAZYF00546 for ; Wed, 24 Apr 2002 13:35:36 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Apr 2002 13:35:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 24 Apr 2002 13:35:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Wed, 24 Apr 2002 13:35:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FD4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHqPgKBpdg8TTb/RTW2pvI40h2wVQBPamvg From: To: , X-OriginalArrivalTime: 24 Apr 2002 10:35:15.0226 (UTC) FILETIME=[B8842FA0:01C1EB7B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28948 Hi all, I think that this can be accomadated - does anyone have misgivings about this? John > -----Original Message----- > From: ext Mark Jones [mailto:mjones@bridgewatersystems.com] > Sent: 22 April, 2002 23:45 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > As I stated earlier, my preference is for a single result > code per message. > If this is acceptable to the WG then building on > Miguel-Angel's earlier text > submission, the following changes are required to the Base > protocol draft: > > --- > > Modify section 7.1, replacing: "All Diameter answer messages > MUST include > one Result-Code AVP" with "All Diameter answer messages > defined in IETF > applications MUST include one Result-Code AVP." > > --- > > Add two new sub-sections to section 7: > > 7.x Vendor-Specific-Result AVP > > The Vendor-Specific-Result AVP (AVP Code tbd) is of type Grouped, and > indicates whether a particular vendor-specific request was completed > successfully or whether an error occurred. Its Data field has > the following > ABNF grammar: > > Vendor-Specific-Result ::= < AVP Header: tbd > > { Vendor-Id } > { Vendor-Specific-Result-Code } > > The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP > identifies the > vendor responsible for the assignment of the result code > which follows. All > Diameter answer messages defined in vendor-specific applications MUST > include either one Result-Code AVP or one > Vendor-Specific-Result-Code AVP. > > 7.y Vendor-Specific-Result-Code AVP > > The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type > Unsigned32 and > contains a vendor-assigned value representing the result of > processing the > request. > > It is recommended that vendor-specific result codes follow the same > conventions given for the Result-Code AVP regarding the > different types of > result codes and the handling of errors (for non 2xxx values). > > --- > > In chapter 4.6: > > After: > ... > Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | > Application-Id | | | | | | > > Add: > > Vendor-Specific- TBD 7.x Grouped | M | P | | V | N | > Result | | | | | | > Vendor-Specific- TBD 7.y Unsigned32 | M | P | | V | N | > Result-Code | | | | | | > > Regards, > Mark > > From owner-aaa-wg@merit.edu Wed Apr 24 12:58:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27911 for ; Wed, 24 Apr 2002 12:58:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B8879123B; Wed, 24 Apr 2002 12:57:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F96E91245; Wed, 24 Apr 2002 12:57:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B9DE9123B for ; Wed, 24 Apr 2002 12:57:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067EF5DE89; Wed, 24 Apr 2002 12:57:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E4A085DE88 for ; Wed, 24 Apr 2002 12:57:53 -0400 (EDT) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id 548517E; Wed, 24 Apr 2002 12:57:53 -0400 (EDT) Message-ID: <008801c1ebb1$022c9720$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Fredrik Johansson" , "Johan Johansson" , "Tony Johansson" Cc: References: Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301 Date: Wed, 24 Apr 2002 12:56:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan and Fredrik and Tony, I'm on vacation so haven't been keeping up on email very well. > From: "Fredrik Johansson" > To: "Johan Johansson" ; > "Tony Johansson" > Cc: "Bob Kopacz" ; > Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301 > Date: Wednesday, April 24, 2002 3:19 AM > > Johan, > > > > >I'll compose a fuller response tomorrow. For now I just want to answer > >one thing. > > > >Tony Johansson wrote: > > > >>goes down you will have a problem. For example, adding the AAAF's > >NAI is also > >>possible, however this is an attempt to optimize scenarios that uses CMS > >>encryption - which may not even be used - and also what happens > >in the case the > >>AAAF in unavailable? Thus, the AAAH receives an AMR with an > >included AAAF NAI and > >>if the AAAF is down - in what way would this then be better > >solved then in the > >>case that AAAH is down.... > >> > >In your suggestion the session ends if the AAAH *or* the AAAF goes down. > > NO, the failover mechanism in diameter-base still makes it possible to > change to another AAAH if the original one is down. The AMR still contains > the HA's identity so it can be reached, what it may not know is the identity > of the AAAF for a possible CVS transaction, but since we're not sure > what/how CMS will work, I would prefer that we go with a solution that we > know works, maybe not optimized in every sence, but it's at least simple. > > Others? I agree with this. Here's my thinking: With Tony's original proposal (where the MN caches HA-identity + AAAH-identity), or with Johan's alternative (where the MN caches HA-identity + Dest-AAAF-identity), I now don't think the session fails if either the original AAAH goes down or the original destination-AAAF goes down. The problem of a (new) AAAH wanting to set up an SA with the destination AAAF, but not knowing the AAAF's identity, may not be such a problem: I've just been told that a DSAR may be sent with a Destination-Realm but without a Destination-Host, when the Destination-Host isn't known. When the DSAA comes back, the node that sent the DSAR then learns the identity of the remote AAA server. If this is true, then the Destination-AAAF's identity may be an optimization more than a requirement. Then, under Tony's original proposal, I think things would work like this: 1. When session is first set up, HA returns HA-NAI and AAAH-NAI to MN, in the Reg Reply. 2. MN caches this info. 3. When MN is handed off to new FA (possibly in new network), MN passes HA-NAI and AAAH-NAI in Reg Req. 4. FA sends AMR to original AAAH. Maybe has to fail over to new AAAH, if original AAAH is down. 5. Whether original-AAAH or new-AAAH handles the AMR, this AAAH has the HA's identity, so can successfully route the HAR. 6a. If new-AAAH needs to set up a DSA to secure HA-MN key, new-AAAH can send DSAR without a Destination-Host. Some AAAF in HA's network will receive the DSAR, and new-AAAH will discover AAAF's identity when the DSAA comes back. 6b. If original-AAAH wants to secure the HA-MN key, the original-AAAH can do [6a] above. Or, since the original-AAAH probably already has a DSA with the destination-AAAF, the original-AAAH can retrieve the destination-AAAF's identity from his cached DSA information. 7. One could add the Dest-AAAF-NAI as a new subtype to the AAA-NAI extension, and the HA could pass this to the MN. The Dest-AAAF's identity can then be bandied about in the AMR. This Dest-AAAF could be treated like a "preferred" AAAF for a DSA by a new-AAAH. But this looks like an optimization. 8. I like the idea of *trying* to stick with one AAAH for a mobile session, for reasons stated in previous emails: [a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new SAs needn't be set up due to an arbitrary AAAH change; [b] Since the AAAH doesn't change, the HA doesn't have to clear the session with the old AAAH when a new AAAH comes on board; [c] Session/policy/resource management is easier with a fixed AAAH, since multiple AAAHs in the same domain may not be synchronized. Is this how others see Tony's original proposal working? If so, then we have a. the virtues of a single AAAH without the requirement of a fixed AAAH, b. the AAAH doesn't become a single point of failure, c. a new AAAH can still secure session keys without foreknowledge of the destination-AAAF. I have no resistance to adding a Dest-AAAF-NAI, if that is useful. > /Fredrik > > >My suggestion has one point of failure less. > > > >j > Bob K. From owner-aaa-wg@merit.edu Thu Apr 25 03:01:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27997 for ; Thu, 25 Apr 2002 03:01:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 675789121E; Thu, 25 Apr 2002 03:00:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB94B912CF; Thu, 25 Apr 2002 03:00:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CC1F9121E for ; Thu, 25 Apr 2002 03:00:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D4A35DDC3; Thu, 25 Apr 2002 03:00:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (unknown [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 398805DDC9 for ; Thu, 25 Apr 2002 03:00:20 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg (liuqb.cwc.nus.edu.sg [172.16.3.32]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id OAA20768 for ; Thu, 25 Apr 2002 14:58:54 +0800 (SGT) Message-Id: <4.3.2.7.2.20020425145947.022b3eb0@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Apr 2002 15:09:47 +0800 To: aaa-wg@merit.edu From: Liu Qiong Bo Subject: Re: [AAA-WG]: [issue] Only DWR/DWA to be used to supervise transportconnection Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi. in Diameter base protocol-10, section5.6, the 2nd paragraph: "This state machine is closely coupled with the state machine described in [AAATRANS], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [AAATRANS] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used." in transport-07, appendix a, there is a failover state machine. I am confused by the state of DOWN in this failover state machine and the state of closed in the peer state machine. In the state of DOWN, does it mean that this transport connection is closed, and the related socket is closed. hence when tw time expires, the diameter node try to open another socket and try to connect to the peer? If it is, then what is the difference between DOWN and closed? Hence what is the complete peer state machine like? Regards. Coral Liu From owner-aaa-wg@merit.edu Thu Apr 25 03:25:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28213 for ; Thu, 25 Apr 2002 03:25:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8286912D1; Thu, 25 Apr 2002 03:25:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 896DE912D2; Thu, 25 Apr 2002 03:25:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5708D912D1 for ; Thu, 25 Apr 2002 03:25:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32EE65DE9F; Thu, 25 Apr 2002 03:25:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C8F1D5DD8C for ; Thu, 25 Apr 2002 03:25:24 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3P7PgF28828 for ; Thu, 25 Apr 2002 10:25:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 25 Apr 2002 10:25:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 25 Apr 2002 10:25:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: FW: Proposal for Resolution of Issue 321: Normative references to CMS Date: Thu, 25 Apr 2002 10:25:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FEA@esebe004.NOE.Nokia.com> Thread-Topic: Proposal for Resolution of Issue 321: Normative references to CMS Thread-Index: AcHqbpBLab7eqHqtTiewG4Ar9QdbbwBu4SAw From: To: X-OriginalArrivalTime: 25 Apr 2002 07:25:23.0546 (UTC) FILETIME=[5CF583A0:01C1EC2A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA28213 Hi all, David Spence proposed the following for seperation of CMS dependencies from the other drafts. Please review this & send comments. The current plan is to adopt the approach, with some additional comments, etc. once I get to editing the document. thanks, John From: David Spence: Last week Frederik Johansson, Tony Johansson, Bob Kopacz, John Vollbrecht, and I discussed the problem of how to remove normative references to CMS from the first batch of Diameter drafts to be standardized. This message documents our conclusions and may be considered as a proposal for resolving this issue in all the drafts. In writing up this proposal I may have embellished or even misunderstood the sense of the conversation. I have not drafted any actual text to implement this proposal but would be glad to once we reach consensus as to how to proceed. One final hint. Use a fixed width font to display the outline below or it will look very ugly. Proposal for Resolution of Issue 321 Normative references to CMS I. The Basic Ideas A. Diameter base, transport, and MobileIPv4 should progress before CMS Security. Diameter is useful in many situations without end-to-end security and should be standardized as quickly as possible. We have made sufficient progress on end-to-end security that we may discuss it in the base draft with some confidence. Nevertheless, we believe it unwise to submit the Diameter CMS Security draft as a proposed standard at this time because we believe that actual implementation and interoperability experience will be crucial to the process of creating a useful and correct specification. B. The framework for Diameter end-to-end security can be described in the base. The concepts defined in the base may then be referenced in Diameter applications. All references to CMS, normative or otherwise, can then be removed from Diameter applications. The base can make a single non-normative reference to the Diameter CMS Security draft as a work in progress toward defining an end-to-end security extension [1] for Diameter. II. The Principles A. Define End-to-End Security in the terminology section. B. CMS references in the base will need to be handled on a case by case basis. Recommendations are given following this outline. C. Generally, CMS references in Diameter applications should be replaced with references to the generic term end-to-end security. D. The only reference to the CMS-sec draft itself should be a non-normative reference in the end-to-end security section of the base (see E, below), where it should be listed as work in progress toward an end-to-end security extension to Diameter. E. Add a section (perhaps a subsection of section 2, Protocol Overview) to discuss the end-to-end security framework. 1. Present the basic components of end-to-end security including encryption and message origin authentication. 2. Define additional terms that may be referenced in the applications. a. Security Association b. A generic term for the DSAR/DSAA message exchange. 3. Indicate that end-to-end security is to be provided by an end-to-end security extension. a. Emphasize that this is not included in the base protocol. b. Cite the CMS draft as a work in progress toward a possible end-to-end security extension. 4. The circumstances requiring the use of end-to-end security are determined by service provider policy. a. This policy is not the subject of standardization. b. This policy may be indexed by next hop Diameter peer or by destination realm. c. Possible granularity for use of end-to-end security may be: 1) Never use end-to-end security if the condition is met. 2) Use end-to-end security on messages containing sensitive AVPs if the condition is met. Which AVPs are sensitive is determined by service provider policy. AVPs containing keys and passwords should be considered sensitive. Accounting AVPs may be considered sensitive. Any AVP for which the P bit may be set or which may be encrypted may be considered sensitive. 3) Always use end-to-end security if the condition is met. 5. Discuss situations in which end-to-end security may be required. Also mention situations such as trusted brokers and settlement agents for which end-to-end security should not be used. E. Diameter applications should alert implementors to potentially sensitive situations where end-to-end security policy SHOULD (MUST?) be consulted. Diameter-MIP contains such alerts for the key AVPs. Diameter-MIP should specify that if policy requires end-to-end security and an end-to-end security association cannot be established then the request should be denied with the specified error code. F. There are two possibilities for how to handle the P bit and may encrypt column. I'm not sure what we decided in our conversation or what would be most appropriate. Please comment. Alternative 1, below grants the most flexibility to the end-to-end security extension itself. Alternative 2 allows implementors to prepare for adding an end-to-end security extension later. Here are the two alternatives. 1. Make no mention of the P bit in the base or applications and delete the may encrypt column. Move this to the CMS-sec draft for the base protocol and any applications already defined. 2. Define the P bit and the meaning of the may encrypt column in the base as part of the requirements for end-to-end security. End Notes [1] We currently use the term Diameter Application for all extensions to Diameter. I suggest we reserve the term Diameter Application to refer to actual applications such as MobileIPv4 and NASREQ, and use the term Diameter Extension for extensions to Diameter that may be used orthogonal to the applications. Both would be numbered out of the same name space, and both could be included in AVPs such as the *-Application-Id AVPs. (Should CMS-sec be included in both Auth-Application-Id and Acct-Application-ID?) * * * * * Recommendations for Handling CMS References in the Base Draft 1. Remove mention of CMS-sec from section 1.1.2, Description of the Document Set. 2. Remove mention of CMS-sec from the beginning of section 2, Protocol Overview. 3. Delete the CMS-sec application identifier from section 2.4. 4. Replace the CMS references in section 2.8.2, Proxy Agents, with references to end-to-end security. 5. In section 4.1, AVP Header, what to do with the CMS reference will depend on what we decide to do with the P bit. (See principle II.F. in the outline, above. 6. Replace the CMS reference in section 4.6, Diameter Base Protocol AVPs with a reference to end-to-end security. 7. The reference to the AAA-Node-Cert AVP in sec. 6.1.7 should be removed. The sentences: Redirect agents MAY also include the certificate of the servers in the Redirect-Host AVP(s). These certificates are encapsulated in a AAA-Node-Cert AVP [CMS]. are inappropriate anyway. Since the Diameter node receiving the redirect will be creating a peer-to-peer connection to the Redirect-Host, there is no need for end-to-end security. 8. The error code 5010, DIAMETER_UNSUPPORTED_TRANSFORM, should be removed from section 7.1.5, Permanent Failures. This code should be defined in the CMS-sec draft. 9. References to AVPs defined in CMS-sec in section 9.5, Accounting Records, should be relaxed to a more general reference to the use of end-to-end security. 10. The following paragraph should be moved from section 9.7.1, Accounting Request, to CMS-sec. When the Accounting-Request is being submitted to a third party (e.g. settlement service), and includes the CMS-Signed-Data AVP [CMS], the CMS-Signed-Data AVP MUST be signed by both the local and home Diameter server using the countersignature procedures described in [CMS]. Actually, I don't think this paragraph is even correct. The home Diameter server is the ultimate destination of the Accounting-Request. So why should it countersign? I suspect it is the third party that should countersign. Also, is the term "local Diameter server" defined anywhere? If not, then use another term -- such as origin Diameter node, origin host, or "the Diameter node indicated by the Origin-Host AVP". 11. The following sentences in 9.7.2, accounting answer should be replaced: If the CMS-Data AVP was present in the Accounting-Request, the corresponding ACA message MUST include the CMS-Data AVP signed by the responder to provide strong AVP authentication, which MAY be used for the purposes of repudiation. For example, state: If the Accounting-Request was protected by end-to-end security, then the corresponding ACA message MUST be protected by end-to-end security. The nonsense about being "used for the purposes of repudiation" should be deleted altogether. 12. The following paragraph in section 13, Security Considerations, is just wrong. When third party brokers or redirect agents are used, strong application level security SHOULD be required, such as non- repudiation. When the communicating peers do require this level of security either for legal or business purposes, the Diameter application defined in [CMS] MAY be used. This security model provides AVP-level authentication, and the encryption mechanism is designed such that only the target host has the keying information required to decrypt the information. It has so many problems, I don't know where to start. First of all, the use of third party brokers does not necessarily indicate that end-to-end security SHOULD be used. Secondly, end-to-end security is useless with the redirect model. Think about it. If I need to use a redirect agent in order to find out what server to send the message to, then how can I create a security association with that server? If you want to keep AVPs private from your redirect agent, then don't send them to your redirect agent! Third, what do we mean by "such as non-repudiation"? Fourth, the term "communicating peers" is a bad choice of words. We use the term peers exclusively to talk about directly connected Diameter nodes. After fixing all those problems, replace the reference to CMS with a reference to end-to-end security. 13. I don't understand the reference to CMS in section 13.2 TLS Usage so I'm not sure how to fix it. 14. Delete the references to CMS in Appendix A. From owner-aaa-wg@merit.edu Thu Apr 25 14:42:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01571 for ; Thu, 25 Apr 2002 14:42:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13FBD91318; Thu, 25 Apr 2002 14:42:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D973991319; Thu, 25 Apr 2002 14:42:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A945C91318 for ; Thu, 25 Apr 2002 14:42:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 911325DED5; Thu, 25 Apr 2002 14:42:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 5993A5DD91 for ; Thu, 25 Apr 2002 14:42:28 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3PIgCi19740 for ; Thu, 25 Apr 2002 13:42:12 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3PIgCb18419 for ; Thu, 25 Apr 2002 13:42:12 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA24167 for ; Thu, 25 Apr 2002 13:42:12 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA17329 for ; Thu, 25 Apr 2002 13:42:11 -0500 (CDT) Message-ID: <3CC84D41.75671D80@ericsson.com> Date: Thu, 25 Apr 2002 11:38:57 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: I-D ACTION:draft-ietf-aaa-diameter-mobileip-10.txt References: <200204251219.IAA02645@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, The following Issues have been added to the new draft: MIP Open Issues Issue Number Status Description Issue 296 MIP-10 Possible new AVP for MobileIPv4 Issue 299 MIP-10 Need more explanation about handling MN handoffs Issue 301 MIP-10 Securing the AAAH-generated session keys Issue 317 MIP-10 HA-FA Key Issue 321 MIP-10 Normative references to CMS Regards, Tony Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. > > Title : Diameter Mobile IPv4 Application > Author(s) : P. Calhoun, T. Johansson, C. Perkins > Filename : draft-ietf-aaa-diameter-mobileip-10.txt > Pages : 48 > Date : 24-Apr-02 > > This document specifies a Diameter application that allows a Diameter > server to authenticate, authorize and collect accounting information > for Mobile IPv4 services rendered to a mobile node. Combined with > the Inter-Domain capability of the base protocol, this application > allows mobile nodes to receive service from foreign service > providers. Diameter Accounting messages will be used by the Foreign > and Home agents to transfer usage information to the Diameter > servers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-10.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-aaa-diameter-mobileip-10.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-aaa-diameter-mobileip-10.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. > > ------------------------------------------------------------------------ From owner-aaa-wg@merit.edu Thu Apr 25 15:09:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02376 for ; Thu, 25 Apr 2002 15:09:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 612FE9131F; Thu, 25 Apr 2002 15:08:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 307B09134C; Thu, 25 Apr 2002 15:08:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E9C99131F for ; Thu, 25 Apr 2002 15:06:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32F525DED6; Thu, 25 Apr 2002 15:06:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web13005.mail.yahoo.com (web13005.mail.yahoo.com [216.136.174.15]) by segue.merit.edu (Postfix) with SMTP id A615C5DE99 for ; Thu, 25 Apr 2002 15:06:21 -0400 (EDT) Message-ID: <20020425190620.11035.qmail@web13005.mail.yahoo.com> Received: from [207.3.232.118] by web13005.mail.yahoo.com via HTTP; Thu, 25 Apr 2002 12:06:20 PDT Date: Thu, 25 Apr 2002 12:06:20 -0700 (PDT) From: Dilip Subject: [AAA-WG]: Question on Relaying Answers Section 6.2.2 To: aaa-wg@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi All I was reading the base protocol Section 6.2.2 Its states "The agent MUST then send the answer to the host that it received the original request from." Question: What if the Host where this answer has to be sent is DOWN(i.e connection has lost) Regards Dilip Patel dilris@yahoo.com ===== Live For Today & not for Tomorrow... As Tomorrow NEVER COMES.. Do Visit My Site at http://www.angelfire.com/in/dilris __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From owner-aaa-wg@merit.edu Thu Apr 25 18:18:29 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07952 for ; Thu, 25 Apr 2002 18:18:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A18591340; Thu, 25 Apr 2002 18:15:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E26F9133F; Thu, 25 Apr 2002 18:15:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E0159133E for ; Thu, 25 Apr 2002 18:15:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 785CB5DEEB; Thu, 25 Apr 2002 18:15:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 135665DDC9 for ; Thu, 25 Apr 2002 18:15:38 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3PMFbi28793 for ; Thu, 25 Apr 2002 17:15:37 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3PMFbb04781 for ; Thu, 25 Apr 2002 17:15:37 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA01569 for ; Thu, 25 Apr 2002 17:15:37 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA20701 for ; Thu, 25 Apr 2002 17:15:36 -0500 (CDT) Message-ID: <3CC87F45.384D7681@ericsson.com> Date: Thu, 25 Apr 2002 15:12:21 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "aaa-wg@merit.edu" Subject: [AAA-WG]: Issue: Diameter Mobile IP application & backwards compatibility Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue: Diameter Mobile IP application & backwards compatibility Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: 2002-04-25 Reference: Document: mip-10 Comment type: T Priority: S Section: Rationale/Explanation of issue: In the existing deployments of Mobile IP clients, especially those that will soon be deployed for IS-835 (the cdma2000 standard). There have been concerns raised about mandating the use of the AAA NAI extension in the mip-10 as it requires restrictions on the client-to-network interface. Requested change: As the mip-10 now is worded the AAA NAI is mandatory to over come the previous found issues, e.g. in cases of multiple AAAH's in the same domain, etc. However, to over come backwards compatibility issues for those that would like to let Mobile IP clients (i.e. those clients that are now deployed) run with the Diameter Mobile IPv4 application with limited functionality, I would like to change the text in the mip-10 draft from a MUST to a SHOULD for the use of the AAA NAI extension. In other words, make the AAA NAI/HA NAI optional and the consequences of not using the AAA NAI/HA NAI would be beyond the scope of the draft. Any comments / objections to this. /Tony From owner-aaa-wg@merit.edu Thu Apr 25 19:54:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09273 for ; Thu, 25 Apr 2002 19:54:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1930191344; Thu, 25 Apr 2002 19:54:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC6AD91345; Thu, 25 Apr 2002 19:54:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B87491344 for ; Thu, 25 Apr 2002 19:54:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8FC25DDBA; Thu, 25 Apr 2002 19:54:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7B23B5DDB2 for ; Thu, 25 Apr 2002 19:54:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g3PN9Vh15096 for ; Thu, 25 Apr 2002 16:09:31 -0700 Date: Thu, 25 Apr 2002 16:09:30 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Last Call on draft-ietf-aaa-diameter-mobileip-10.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of AAA WG last call on the Diameter MIPv4 specification, before sending this on to the IESG for consideration as a Proposed Standard. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-10.txt Please post issues with this document to aaa-wg@merit.edu by May 15, 2002, using the issue format described on the AAA issues list at: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Thu Apr 25 22:43:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13950 for ; Thu, 25 Apr 2002 22:43:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5C589134C; Thu, 25 Apr 2002 22:42:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AF2B9134E; Thu, 25 Apr 2002 22:42:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2ACF29134C for ; Thu, 25 Apr 2002 22:42:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CC195DE05; Thu, 25 Apr 2002 22:42:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 24DCB5DDC0 for ; Thu, 25 Apr 2002 22:42:25 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg (liuqb.cwc.nus.edu.sg [172.16.3.32]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id KAA07728 for ; Fri, 26 Apr 2002 10:40:48 +0800 (SGT) Message-Id: <4.3.2.7.2.20020426101509.022d8e88@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Apr 2002 10:46:22 +0800 To: aaa-wg@merit.edu From: Liu Qiong Bo Subject: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Qiong Bo Liu Submitter email address: liuqb@cwc.nus.edu.sg Date first submitted: April 26, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03954.html Document: base-10, transport-07 Comment type: T Priority: ? Section: 5.6 in base, 3.4.1 and appendix A in transport Rationale/Explanation of issue: in Diameter base protocol-10, section5.6, the 2nd paragraph: "This state machine is closely coupled with the state machine described in [AAATRANS], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [AAATRANS] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used." in transport-07, appendix A, there is a failover state machine with a state of DOWN. In the state of DOWN, does it mean that this transport connection is closed, and the related socket is closed. hence when tw time expires, the diameter node try to open another socket and try to connect to the peer? If it is, then what is the difference between DOWN and closed? Requested change: suggest to give a complete peer state machine combining with failover state machine From owner-aaa-wg@merit.edu Thu Apr 25 22:51:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14111 for ; Thu, 25 Apr 2002 22:51:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D83D9134E; Thu, 25 Apr 2002 22:51:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C98D9134F; Thu, 25 Apr 2002 22:51:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEFCD9134E for ; Thu, 25 Apr 2002 22:51:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA7475DE07; Thu, 25 Apr 2002 22:51:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 6B1E85DDC0 for ; Thu, 25 Apr 2002 22:51:05 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg (liuqb.cwc.nus.edu.sg [172.16.3.32]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id KAA09021 for ; Fri, 26 Apr 2002 10:49:55 +0800 (SGT) Message-Id: <4.3.2.7.2.20020426105613.022d8058@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Apr 2002 11:00:47 +0800 To: aaa-wg@merit.edu From: Liu Qiong Bo Subject: [AAA-WG]: delete Snd-Conn-Ack Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi. in base-10, section 5.6.3, one action named Snd-Conn-Ack is defined, but it doesn't appear in the peer state machine. Therefore suggest to delete this action from the document. regards. Coral From owner-aaa-wg@merit.edu Mon Apr 29 03:36:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07316 for ; Mon, 29 Apr 2002 03:36:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABF4491205; Mon, 29 Apr 2002 03:36:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FD4491208; Mon, 29 Apr 2002 03:36:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EA3B91205 for ; Mon, 29 Apr 2002 03:36:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13E2F5DED4; Mon, 29 Apr 2002 03:36:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 665ED5DD94 for ; Mon, 29 Apr 2002 03:36:30 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3T7aSs7017166 for ; Mon, 29 Apr 2002 09:36:29 +0200 (MEST) Received: FROM esealnt744.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 09:38:30 2002 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 09:36:28 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED21CF@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'john.loughney@nokia.com'" , mjones@bridgewatersystems.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Mon, 29 Apr 2002 09:33:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, One minor editorial comment: Where it says: "All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Vendor-Specific-Result-Code AVP." It should say: "All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Vendor-Specific-Result AVP." Regards, Miguel > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 24, 2002 6:35 AM > To: mjones@bridgewatersystems.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Hi all, > > I think that this can be accomadated - does anyone have misgivings > about this? > > John > > > -----Original Message----- > > From: ext Mark Jones [mailto:mjones@bridgewatersystems.com] > > Sent: 22 April, 2002 23:45 > > To: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > > > > As I stated earlier, my preference is for a single result > > code per message. > > If this is acceptable to the WG then building on > > Miguel-Angel's earlier text > > submission, the following changes are required to the Base > > protocol draft: > > > > --- > > > > Modify section 7.1, replacing: "All Diameter answer messages > > MUST include > > one Result-Code AVP" with "All Diameter answer messages > > defined in IETF > > applications MUST include one Result-Code AVP." > > > > --- > > > > Add two new sub-sections to section 7: > > > > 7.x Vendor-Specific-Result AVP > > > > The Vendor-Specific-Result AVP (AVP Code tbd) is of type > Grouped, and > > indicates whether a particular vendor-specific request was completed > > successfully or whether an error occurred. Its Data field has > > the following > > ABNF grammar: > > > > Vendor-Specific-Result ::= < AVP Header: tbd > > > { Vendor-Id } > > { Vendor-Specific-Result-Code } > > > > The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP > > identifies the > > vendor responsible for the assignment of the result code > > which follows. All > > Diameter answer messages defined in vendor-specific > applications MUST > > include either one Result-Code AVP or one > > Vendor-Specific-Result-Code AVP. > > > > 7.y Vendor-Specific-Result-Code AVP > > > > The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type > > Unsigned32 and > > contains a vendor-assigned value representing the result of > > processing the > > request. > > > > It is recommended that vendor-specific result codes follow the same > > conventions given for the Result-Code AVP regarding the > > different types of > > result codes and the handling of errors (for non 2xxx values). > > > > --- > > > > In chapter 4.6: > > > > After: > > ... > > Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | > > Application-Id | | | | | | > > > > Add: > > > > Vendor-Specific- TBD 7.x Grouped | M | P | | V | N | > > Result | | | | | | > > Vendor-Specific- TBD 7.y Unsigned32 | M | P | | V | N | > > Result-Code | | | | | | > > > > Regards, > > Mark > > > > > From owner-aaa-wg@merit.edu Tue Apr 30 06:26:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12111 for ; Tue, 30 Apr 2002 06:26:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A730791203; Tue, 30 Apr 2002 06:25:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CF7891206; Tue, 30 Apr 2002 06:25:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31FF091203 for ; Tue, 30 Apr 2002 06:25:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDD915DE44; Tue, 30 Apr 2002 06:25:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by segue.merit.edu (Postfix) with ESMTP id 339025DDB7 for ; Tue, 30 Apr 2002 06:25:52 -0400 (EDT) Received: from jobim (jobim [157.159.100.41]) by hugo.int-evry.fr (8.8.8/jtpda-5.3) with ESMTP id MAA03335 for ; Tue, 30 Apr 2002 12:25:43 +0200 (MET DST) Date: Tue, 30 Apr 2002 12:25:45 +0200 (MET DST) From: julien Bournelle X-Sender: bournell@jobim Reply-To: julien.bournelle@int-evry.fr To: aaa-wg@merit.edu Subject: [AAA-WG]: typos in mobile-ip draft 10 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id GAA12111 Hi, I've just noticed 2 typos in draft 10 concerning Mobile IPv4 application: p.6 §1.2 "When a Mobile Node node requests..." => "When a Mobile Node requests" p.19 §2.2 "An AMA message ...., MUST include the MIP-Home-Mobile-Node-Address AVP.." => "An AMA message ..., MUST include the MIP-Mobile-Node-Address AVP" Hope it helps, julien.bournelle@int-evry.fr From owner-aaa-wg@merit.edu Tue Apr 30 08:14:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15382 for ; Tue, 30 Apr 2002 08:13:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B07A9122C; Tue, 30 Apr 2002 08:12:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8C3C9123D; Tue, 30 Apr 2002 08:12:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC85A9122C for ; Tue, 30 Apr 2002 08:12:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 849175DF34; Tue, 30 Apr 2002 08:12:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id B399E5DEA0 for ; Tue, 30 Apr 2002 08:12:01 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g3UCC2200346 for ; Tue, 30 Apr 2002 14:12:02 +0200 Message-ID: <3CCE89D6.7090804@ipunplugged.com> Date: Tue, 30 Apr 2002 14:11:02 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: 2002-April-30 Document: base (could also be that mip is the correct one) Comment type: T Priority: S Section: 9.6 Rationale/Explanation of issue: What is the relationship between session ids of authorizing sessions and accounting sessions, i.e. is there a difference between the authorizing session and the accounting one? There seems to be certain advantages to saying that they are separate sessions as I will describe below and I am not aware of any real benefit from saying that they are to be regarded as the same session. All relevant information is transported in each ACR and thus there seem to be little to be gained by correlating the accounting and authorization sessions based on the value of the Session-Id AVP. Differences between implementations will inevitably lead to interopability problems. The following scenario is from the mip application, but it boils down to whether accounting sessions have the same id as authorization sessions. The AAAH server may change for a variety of reasons, but the home agent (HA) must remain the same for the duration of the Mobile IP session. When a foreign agent (FA) sends an authorization request the AAAH initates a session involving the home agent. Since we have moved to a new AAAH the HA will receive a request for a session whose id is different from the one already active for the same user on the HA. According to the mip application the HA must replace it's existing session with the new one while retaining the same Acct-Multi-Session-Id. The follow-up question to this is what happens to the accounting. Do we send a new start record and start from scratch or do we continue with our existing accounting session? In many ways it would be more elegant and leave less room for errors to keep the existing accounting session, but this would require that it is in fact a separate session. I am not sure whether this is properly a base or mip issue since section 9.6. states A Diameter application document MUST define the exact concept of a session that is being accounted but the issue itself is quite fundamental. Requested change: The Diameter protocol's Session-Id AVP, which is globally unique (see section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. to The Diameter protocol's Session-Id AVP, which is globally unique (see section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. Accounting messages MUST use a different Session-Id from that sent in authorization messages. j From owner-aaa-wg@merit.edu Tue Apr 30 08:17:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15498 for ; Tue, 30 Apr 2002 08:17:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECE0691230; Tue, 30 Apr 2002 08:17:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEDC79122F; Tue, 30 Apr 2002 08:17:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41A2191231 for ; Tue, 30 Apr 2002 08:16:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11ACC5DF35; Tue, 30 Apr 2002 08:16:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5D9D05DEA0 for ; Tue, 30 Apr 2002 08:16:55 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3UCHEF01878 for ; Tue, 30 Apr 2002 15:17:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Apr 2002 15:16:54 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 30 Apr 2002 15:16:54 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Apr 2002 15:16:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Date: Tue, 30 Apr 2002 15:16:53 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF2718401682767@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Thread-Index: AcHwQIMJ9G21ON4TSPWxrDW4cZFxxgAAClfg From: To: , X-OriginalArrivalTime: 30 Apr 2002 12:16:53.0942 (UTC) FILETIME=[EA1CE560:01C1F040] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15498 Hi, This change seems very reansonable to me. br, JPK -----Original Message----- From: ext Johan Johansson [mailto:johanj@ipunplugged.com] Sent: 30. April 2002 15:11 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: 2002-April-30 Document: base (could also be that mip is the correct one) Comment type: T Priority: S Section: 9.6 Rationale/Explanation of issue: What is the relationship between session ids of authorizing sessions and accounting sessions, i.e. is there a difference between the authorizing session and the accounting one? There seems to be certain advantages to saying that they are separate sessions as I will describe below and I am not aware of any real benefit from saying that they are to be regarded as the same session. All relevant information is transported in each ACR and thus there seem to be little to be gained by correlating the accounting and authorization sessions based on the value of the Session-Id AVP. Differences between implementations will inevitably lead to interopability problems. The following scenario is from the mip application, but it boils down to whether accounting sessions have the same id as authorization sessions. The AAAH server may change for a variety of reasons, but the home agent (HA) must remain the same for the duration of the Mobile IP session. When a foreign agent (FA) sends an authorization request the AAAH initates a session involving the home agent. Since we have moved to a new AAAH the HA will receive a request for a session whose id is different from the one already active for the same user on the HA. According to the mip application the HA must replace it's existing session with the new one while retaining the same Acct-Multi-Session-Id. The follow-up question to this is what happens to the accounting. Do we send a new start record and start from scratch or do we continue with our existing accounting session? In many ways it would be more elegant and leave less room for errors to keep the existing accounting session, but this would require that it is in fact a separate session. I am not sure whether this is properly a base or mip issue since section 9.6. states A Diameter application document MUST define the exact concept of a session that is being accounted but the issue itself is quite fundamental. Requested change: The Diameter protocol's Session-Id AVP, which is globally unique (see section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. to The Diameter protocol's Session-Id AVP, which is globally unique (see section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. Accounting messages MUST use a different Session-Id from that sent in authorization messages. j From owner-aaa-wg@merit.edu Tue Apr 30 08:54:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18056 for ; Tue, 30 Apr 2002 08:54:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF9229122F; Tue, 30 Apr 2002 08:54:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64E5491232; Tue, 30 Apr 2002 08:54:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31FB79122F for ; Tue, 30 Apr 2002 08:54:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 041125DF6A; Tue, 30 Apr 2002 08:54:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id A9D775DF5D for ; Tue, 30 Apr 2002 08:54:04 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id IAA02317; Tue, 30 Apr 2002 08:44:01 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.3) with SMTP id IAA26814; Tue, 30 Apr 2002 08:56:29 -0400 (EDT) From: "Mark Jones" To: "Miguel-Angel Pallares-Lopez (ECE)" , Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Tue, 30 Apr 2002 08:56:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <577066326047D41180AC00508B955DDA05ED21CF@eestqnt104> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > One minor editorial comment: > > Where it says: > "All Diameter answer messages defined in vendor-specific > applications MUST include either one Result-Code AVP or one > Vendor-Specific-Result-Code AVP." > > It should say: > "All Diameter answer messages defined in vendor-specific > applications MUST include either one Result-Code AVP or one > Vendor-Specific-Result AVP." > Agreed. Well spotted, Miguel. Regards, Mark From owner-aaa-wg@merit.edu Tue Apr 30 17:52:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10202 for ; Tue, 30 Apr 2002 17:52:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5F319123C; Tue, 30 Apr 2002 17:52:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95F209123D; Tue, 30 Apr 2002 17:52:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 838479123C for ; Tue, 30 Apr 2002 17:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57B7E5E13F; Tue, 30 Apr 2002 17:52:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id CD7375DEE8 for ; Tue, 30 Apr 2002 17:52:13 -0400 (EDT) Received: (cpmta 12840 invoked from network); 30 Apr 2002 14:52:13 -0700 Received: from 24.147.221.194 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 30 Apr 2002 14:52:13 -0700 X-Sent: 30 Apr 2002 21:52:13 GMT Message-Id: <5.1.0.14.2.20020430175046.037de6e0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 17:51:51 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 4/30/2002 02:11 PM +0200, Johan Johansson wrote: >Submitter name: Johan Johansson >Submitter email address: johanj@ipunplugged.com >Date first submitted: 2002-April-30 >Document: base (could also be that mip is the correct one) >Comment type: T >Priority: S >Section: 9.6 >Rationale/Explanation of issue: > >What is the relationship between session ids of authorizing sessions and >accounting sessions, i.e. is there a difference between the authorizing >session and the accounting one? There seems to be certain advantages to >saying that they are separate sessions as I will describe below and I am >not aware of any real benefit from saying that they are to be regarded as >the same session. Sorry, I don't get it. Why do I want to have to create two different identifiers for the same session? >All relevant information is transported in each ACR and thus there seem to >be little to be gained by correlating the accounting and authorization >sessions based on the value of the Session-Id AVP. less work? >Differences between implementations will inevitably lead to interopability >problems. that's for xxx sure! >The following scenario is from the mip application, but it boils down to >whether accounting sessions have the same id as authorization sessions. >The AAAH server may change for a variety of reasons, but the home agent >(HA) must remain the same for the duration of the Mobile IP session. When >a foreign agent (FA) sends an authorization request the AAAH initates a >session involving the home agent. Since we have moved to a new AAAH the HA >will receive a request for a session whose id is different from the one >already active for the same user on the HA. According to the mip >application the HA must replace it's existing session with the new one >while retaining the same Acct-Multi-Session-Id. The follow-up question to >this is what happens to the accounting. Do we send a new start record and >start from scratch or do we continue with our existing accounting session? >In many ways it would be more elegant and leave less room for errors to >keep the existing accounting session, but this would require that it is in >fact a separate session. > >I am not sure whether this is properly a base or mip issue since section >9.6. states > >A Diameter application document MUST define the exact concept of a > session that is being accounted > >but the issue itself is quite fundamental. This smells like a MIP issue. Most NAS applications wouldn't have this problem. The problem is why is the session identifier changing? Presumably, because some part of the session is moving/changing servers. Either at the access end or the HA end. This begs a philosophical question, what is the true session identifer? Or more practically, what do we need to identify? My gut says that the start of access from the MN to the network until hang-up is the "true session". All handoffs and migrations are part of a MIP session continuity problem. The MIP design should take this into account and provide the accounting with sufficent information to be able to track and charge appropriately. This may entail a unique core session identifier, and sub identifiers for different configurations along the way. Dave.