Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 May 2004 14:55:56 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Mon, 31 May 2004 11:00:44 -0400 Message-Id: <20040531150044.C8D0B16E1B@mail.nitros9.org> Nakhjiri Madjid-MNAKHJI1 wrote: > Sorry for the delayed response. I saw the draft and read it, was > interested in it too. But I heard it went to another working group > (enroll), true? Yes and no. Bob has been pushing SSPP for a while, in a number of groups. So far, there haven't been many takers. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 May 2004 16:01:19 +0000 Date: Fri, 28 May 2004 09:03:27 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: Rationalizing the RADIUS data model Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > So I don't know what the benefit of having a new class of attribute. What > are we really fixing here? Presumably what we would be fixing is: a. Providing a migration path from current SDO VSAs to the IETF standards space. b. Rationalizing the RADIUS VSA data model with the IETF standard attribute data model. Today because the data models are different and the IETF standards space is only 8 bits, we have difficulties in migrating arbitrary SDO VSAs to the IETF standards space. To get there, I'd suggest we need to do the following: 1. Take inventory of the data types used in current RADIUS RFCs. We've discussed this on previous emails, but we still need to summarize this and draw conclusions from it so we can understand what the current RADIUS data model is. 2. Take inventory of the data types that folks feel they need/want going forward. Certainly sub-attributes are one element of this, but there is probably more as well (such as an IPv6 address type). 3. Put together a draft summarizing what we have now, and analyzing where we need to go, including the Diameter/RADIUS translation issues. In terms of attribute definition, we have two proposals on the table: a. Using a Vendor-Id of zero (0) within the existing VSA attribute 26, in order to define an extended IETF standard attribute space that would mirror the VSA data model, including support for sub-attributes. b. Creating a new attribute that would mirror the VSA data model, including support for subattributes. As I understand it, the primary argument for b) over a) relates to potential backward compatibility issues with a). To determine whether this is an issue or not we will need to survey existing implementations. Proposal for an IETF extended attribute space: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) |M|R| Vendor type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 26 for Vendor-Specific Length >= 7 Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. A value of zero (0) denotes the IETF extended attribute space. M 1 = Mandatory 0 = Non-mandatory R Reserved for future use, and set to zero (0). Vendor type The vendor type field is 14 bits. Vendor length The Vendor Length field is one octet, and indicates the length of this Attribute in octets, including the M, R, Vendor type, Vendor length and Attribute-Specific fields. Attribute-specific The Attribute-Specific field is dependent on the definition of the Attribute. Multiple subattributes MAY be encoded within a single IETF extended attribute, although they do not have to be. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 May 2004 15:28:04 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Alan DeKok'" , radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Fri, 28 May 2004 10:27:34 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Alan, Sorry for the delayed response. I saw the draft and read it, was interested in it too. But I heard it went to another working group (enroll), true? Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Alan DeKok Sent: Wednesday, May 19, 2004 6:20 PM To: radiusext@ops.ietf.org Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter "Kuntal Chowdhury" wrote: > MN-HA shared secret can be changed every moment or may be static (other end > of the spectrum). Distribution of static pre-configured keys (not derived) > is not a good crypto practice. May be we should ask security area experts to > comment on key distribution. Robert Moskowitz & I proposed a key bootstrap & distribution method for RADIUS clients (client kickstart). It's not exactly the same thing, but it's related. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 May 2004 09:41:16 +0000 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476AA57@eestqnt105.es.eu.ericsson.se> From: "David Mariblanca (ML/EEM)" To: aaa-wg@merit.edu Cc: radiusext@ops.ietf.org Subject: FW: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt Date: Wed, 26 May 2004 11:40:52 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C44305.88FFA921" 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_000_01C44305.88FFA921 Content-Type: text/plain; charset="ISO-8859-1" Hi all, probably you have read this announcement. Comments to the paper are welcome, please send them to this AAA WG list. Thanks and best regards, David. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: martes, 25 de mayo de 2004 17:03 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP lower layer attributes for AAA protocols Author(s) : D. Mariblanca Filename : draft-mariblanca-aaa-eap-lla-00.txt Pages : 6 Date : 2004-5-24 This document defines a new AVP to be transported in RADIUS or Diameter when EAP is carried over these protocols. The purpose of this AVP is to determine which layer 2 protocol was used to encapsulate the EAP messages at the point they were initiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mariblanca-aaa-eap-lla-00.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-mariblanca-aaa-eap-lla-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C44305.88FFA921 Content-Type: message/rfc822 To: Subject: Date: Wed, 26 May 2004 11:40:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C44305.88FFA921" ------_=_NextPart_002_01C44305.88FFA921 Content-Type: text/plain ------_=_NextPart_002_01C44305.88FFA921 Content-Type: application/octet-stream; name="ATT34897" Content-Disposition: attachment; filename="ATT34897" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-24153224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt ------_=_NextPart_002_01C44305.88FFA921 Content-Type: message/external-body; site="internet-drafts"; dir="draft-mariblanca-aaa-eap-lla-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C44305.88FFA921-- ------_=_NextPart_000_01C44305.88FFA921 Content-Type: text/plain; name="ATT3489756.txt" Content-Disposition: attachment; filename="ATT3489756.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C44305.88FFA921-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 17:23:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: WG Review: RADIUS Extensions (radext) Date: Thu, 20 May 2004 13:20:50 -0400 Message-ID: Thread-Topic: WG Review: RADIUS Extensions (radext) Thread-Index: AcQ+jbYDoMcR2xnWTHqCmYLjDuRhsQAAPfqA From: "Nelson, David" To: A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by May 26th. RADIUS Extensions (radext) --------------------------- Current Staus: Proposed Working Group Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. In order to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes, including discussion of the appropriate use of RADIUS SDO-Specific Attributes (SSAs). This document will also review RADIUS data types and associated backwards compatibility issues. - RADIUS implementation issues and fixes. This document will address common RADIUS implementation issues and describe proposed solutions. - Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to correct known errors, add support for privacy and internationalization, and provide more details on routing. - Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will include within it a specification for interoperation with Diameter Credit Control. - SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability. This document will be upwards compatible with the Diameter SIP application, and conform to existing IETF RFCs on HTTP Digest, including RFC 2617, 3261, and 3310. - LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. - RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest changes are required to address this issue. MIBs for RFC 3576 are also needed.=20 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------- End of Forwarded Message -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 16:19:00 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Nelson, David'" , radiusext@ops.ietf.org, "'Bernard Aboba'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 11:18:22 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Dave, Bernard, I appreciate the work the chairs and IESG are going through to approve the charter. So I don't want to jeopardize anything for now. Is it possible to have a 5-10 minute slot to present the problem to the group/birds :), for future consideration? I am not sure if I can put a draft together by next IETF, but it is not completely out of question! Regards, Madjid -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com] Sent: Wednesday, May 19, 2004 5:02 PM To: Nakhjiri Madjid-MNAKHJI1; Kuntal Chowdhury; radiusext@ops.ietf.org Cc: Pete McCann; tom.hiller@lucent.com; Charles E.Perkins Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > I still have a question for the group and chairs? > Is the group saying: go to Diameter for those needs? or there is not > enough room in charter now? or people are not interested? or as Bernard > said the group only wants to deal with other SDOs? The charter is currently in IESG review. The announcement went out to the IETF-Announce list today. There is quite a bit of work on the charter now. Unless there is an urgent requirement from 3GPP or 3GPP2 for this work, or unless another IETF WG requests it, it would seem inadvisable to take on this additional work now. There is always the possibility of re-chartering after all (or most) of our current deliverables have been achieved. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 16:15:09 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" Cc: radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter Date: Thu, 20 May 2004 11:13:34 -0500 MIME-Version: 1.0 Content-Type: text/plain A peach in mind is not a bad thing maybe, I like the smell :) -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: Thursday, May 20, 2004 10:35 AM To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' Cc: Lila Madour (QA/EMC); radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter s/peach/peace >-----Original Message----- >From: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Sent: Thursday, May 20, 2004 10:03 AM >To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' >Cc: Lila Madour (QA/EMC); radiusext@ops.ietf.org; Pete McCann; >tom.hiller@lucent.com >Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >support??: RAD EXT WG Charter > > >I will not loose my peach of mind if people want to spend time >on MIP4-RADIUS work. However, I don't see the need for it. > >If it is so important, then a generic (dynamic) key >distribution mechanism with RADIUS may be of some interest to me. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Thursday, May 20, 2004 9:47 AM >>To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH] >>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >>support??: RAD EXT WG Charter >> >> >>Hi Kuntal >> >>I agree what Charlie. The problems of RADIUS supporting Mobile >>IP extensions and RADIUS hop by hop security are different. >>Although solutions to both is required for some scenarios, >>that is not always the case. Lets remember I am not asking >>radext to solve all MIP security problems (if they exist). >>If I had issues with security of MIP, I would go to MIP >>mailing list, not this list. And for folks interested in those >>issues, please lets meet over at MIP list! >>I am saying MIPv4 and its key mgmt drafts as protocols being >>standardized by IETF need support for RADIUS, which also is an >>IETF protocol. For folks that argue 3GPP2 has done it this >>way or the other, I should say: >>The interoperability problems for IETF protocols "Must" be >>resolved in IETF, not in other SDOs. What would you tell IEEE >>folks, or APCO folks? Please go to 3GPP32 for the second half >>of the solution? >> >>IETF AAA community has acknowledged RADIUS problems and solved >>many of those in Diameter, but Diameter has a small deployment >>base, please show me a Diameter vendor that supports all IETF >>specs and I may just go buy from them. >>The problem is people are stuck with RADIUS for a while and if >>you are using Mobile IP, problems needs to be solved. >> >>I can understand the group might be having a pressing charter, >>but I don't buy the argument of "there is no need because >>3GPP2 has done it since 2000". Technology grows! >> >>Regards, >> >>Madjid >> >> >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Wednesday, May 19, 2004 7:50 PM >>To: Kuntal Chowdhury >>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >>support??: RADEXT WG Charter >> >> >>Hello Kuntal, >> >>> Kuntal Chowdhury wrote: >>> >>>We cannot assume that the HA and the HAAA server SHALL always >>be in the >>>same administrative domain. >>> >>That means another solution is required for expanded >>applicability. It doesn't mean that the offered solution is >>inappropriate for its domain of applicability. >> >>> Moreover, for RADIUS, every proxy in the PATH will >>>see the MN-HA shared secret. >>> >>> >>Well, since the secret didn't exist at all anyway until the >>AAAH created it, I don't see the big deal here. If there is >>some worry, then: >>(a) use a shorter lifetime and/or >>(b) use another key when moving to another domain >> >>>Again, this issue should be discussed with security area folks. >>> >>> >>They've looked at it pretty close a few dozen >>times by now I reckon. >> >>Regards, >>Charlie P. >> > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 15:36:39 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2B54@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: "Lila Madour (QA/EMC)" , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter Date: Thu, 20 May 2004 11:35:24 -0400 MIME-Version: 1.0 Content-Type: text/plain s/peach/peace >-----Original Message----- >From: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Sent: Thursday, May 20, 2004 10:03 AM >To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' >Cc: Lila Madour (QA/EMC); radiusext@ops.ietf.org; Pete McCann; >tom.hiller@lucent.com >Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >support??: RAD EXT WG Charter > > >I will not loose my peach of mind if people want to spend time >on MIP4-RADIUS work. However, I don't see the need for it. > >If it is so important, then a generic (dynamic) key >distribution mechanism with RADIUS may be of some interest to me. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Thursday, May 20, 2004 9:47 AM >>To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH] >>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >>support??: RAD EXT WG Charter >> >> >>Hi Kuntal >> >>I agree what Charlie. The problems of RADIUS supporting Mobile >>IP extensions and RADIUS hop by hop security are different. >>Although solutions to both is required for some scenarios, >>that is not always the case. Lets remember I am not asking >>radext to solve all MIP security problems (if they exist). >>If I had issues with security of MIP, I would go to MIP >>mailing list, not this list. And for folks interested in those >>issues, please lets meet over at MIP list! >>I am saying MIPv4 and its key mgmt drafts as protocols being >>standardized by IETF need support for RADIUS, which also is an >>IETF protocol. For folks that argue 3GPP2 has done it this >>way or the other, I should say: >>The interoperability problems for IETF protocols "Must" be >>resolved in IETF, not in other SDOs. What would you tell IEEE >>folks, or APCO folks? Please go to 3GPP32 for the second half >>of the solution? >> >>IETF AAA community has acknowledged RADIUS problems and solved >>many of those in Diameter, but Diameter has a small deployment >>base, please show me a Diameter vendor that supports all IETF >>specs and I may just go buy from them. >>The problem is people are stuck with RADIUS for a while and if >>you are using Mobile IP, problems needs to be solved. >> >>I can understand the group might be having a pressing charter, >>but I don't buy the argument of "there is no need because >>3GPP2 has done it since 2000". Technology grows! >> >>Regards, >> >>Madjid >> >> >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Wednesday, May 19, 2004 7:50 PM >>To: Kuntal Chowdhury >>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >>support??: RADEXT WG Charter >> >> >>Hello Kuntal, >> >>> Kuntal Chowdhury wrote: >>> >>>We cannot assume that the HA and the HAAA server SHALL always >>be in the >>>same administrative domain. >>> >>That means another solution is required for expanded >>applicability. It doesn't mean that the offered solution is >>inappropriate for its domain of applicability. >> >>> Moreover, for RADIUS, every proxy in the PATH will >>>see the MN-HA shared secret. >>> >>> >>Well, since the secret didn't exist at all anyway until the >>AAAH created it, I don't see the big deal here. If there is >>some worry, then: >>(a) use a shorter lifetime and/or >>(b) use another key when moving to another domain >> >>>Again, this issue should be discussed with security area folks. >>> >>> >>They've looked at it pretty close a few dozen >>times by now I reckon. >> >>Regards, >>Charlie P. >> > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 15:03:52 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2A5B@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: "Lila Madour (QA/EMC)" , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter Date: Thu, 20 May 2004 11:03:15 -0400 MIME-Version: 1.0 Content-Type: text/plain I will not loose my peach of mind if people want to spend time on MIP4-RADIUS work. However, I don't see the need for it. If it is so important, then a generic (dynamic) key distribution mechanism with RADIUS may be of some interest to me. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Thursday, May 20, 2004 9:47 AM >To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >support??: RAD EXT WG Charter > > >Hi Kuntal > >I agree what Charlie. The problems of RADIUS supporting Mobile >IP extensions and RADIUS hop by hop security are different. >Although solutions to both is required for some scenarios, >that is not always the case. Lets remember I am not asking >radext to solve all MIP security problems (if they exist). >If I had issues with security of MIP, I would go to MIP >mailing list, not this list. And for folks interested in those >issues, please lets meet over at MIP list! >I am saying MIPv4 and its key mgmt drafts as protocols being >standardized by IETF need support for RADIUS, which also is an >IETF protocol. For folks that argue 3GPP2 has done it this >way or the other, I should say: >The interoperability problems for IETF protocols "Must" be >resolved in IETF, not in other SDOs. What would you tell IEEE >folks, or APCO folks? Please go to 3GPP32 for the second half >of the solution? > >IETF AAA community has acknowledged RADIUS problems and solved >many of those in Diameter, but Diameter has a small deployment >base, please show me a Diameter vendor that supports all IETF >specs and I may just go buy from them. >The problem is people are stuck with RADIUS for a while and if >you are using Mobile IP, problems needs to be solved. > >I can understand the group might be having a pressing charter, >but I don't buy the argument of "there is no need because >3GPP2 has done it since 2000". Technology grows! > >Regards, > >Madjid > > >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 7:50 PM >To: Kuntal Chowdhury >Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >support??: RADEXT WG Charter > > >Hello Kuntal, > >> Kuntal Chowdhury wrote: >> >>We cannot assume that the HA and the HAAA server SHALL always >be in the >>same administrative domain. >> >That means another solution is required for expanded >applicability. It doesn't mean that the offered solution is >inappropriate for its domain of applicability. > >> Moreover, for RADIUS, every proxy in the PATH will >>see the MN-HA shared secret. >> >> >Well, since the secret didn't exist at all anyway until the >AAAH created it, I don't see the big deal here. If there is >some worry, then: >(a) use a shorter lifetime and/or >(b) use another key when moving to another domain > >>Again, this issue should be discussed with security area folks. >> >> >They've looked at it pretty close a few dozen >times by now I reckon. > >Regards, >Charlie P. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:46:57 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Kuntal Chowdhury Cc: "Lila Madour (QA/EMC)" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter Date: Thu, 20 May 2004 09:46:41 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kuntal I agree what Charlie. The problems of RADIUS supporting Mobile IP extensions and RADIUS hop by hop security are different. Although solutions to both is required for some scenarios, that is not always the case. Lets remember I am not asking radext to solve all MIP security problems (if they exist). If I had issues with security of MIP, I would go to MIP mailing list, not this list. And for folks interested in those issues, please lets meet over at MIP list! I am saying MIPv4 and its key mgmt drafts as protocols being standardized by IETF need support for RADIUS, which also is an IETF protocol. For folks that argue 3GPP2 has done it this way or the other, I should say: The interoperability problems for IETF protocols "Must" be resolved in IETF, not in other SDOs. What would you tell IEEE folks, or APCO folks? Please go to 3GPP32 for the second half of the solution? IETF AAA community has acknowledged RADIUS problems and solved many of those in Diameter, but Diameter has a small deployment base, please show me a Diameter vendor that supports all IETF specs and I may just go buy from them. The problem is people are stuck with RADIUS for a while and if you are using Mobile IP, problems needs to be solved. I can understand the group might be having a pressing charter, but I don't buy the argument of "there is no need because 3GPP2 has done it since 2000". Technology grows! Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, May 19, 2004 7:50 PM To: Kuntal Chowdhury Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RADEXT WG Charter Hello Kuntal, > Kuntal Chowdhury wrote: > >We cannot assume that the HA and the HAAA server SHALL always be in the same >administrative domain. > That means another solution is required for expanded applicability. It doesn't mean that the offered solution is inappropriate for its domain of applicability. > Moreover, for RADIUS, every proxy in the PATH will >see the MN-HA shared secret. > > Well, since the secret didn't exist at all anyway until the AAAH created it, I don't see the big deal here. If there is some worry, then: (a) use a shorter lifetime and/or (b) use another key when moving to another domain >Again, this issue should be discussed with security area folks. > > They've looked at it pretty close a few dozen times by now I reckon. Regards, Charlie P. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:39:01 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2987@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Alan DeKok , radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 10:38:43 -0400 MIME-Version: 1.0 Content-Type: text/plain This seems to make lot more sense to me than creating a distribution method for static shared secrets over RADIUS. I did not read your draft yet. -Kuntal >-----Original Message----- >From: Alan DeKok [mailto:aland@ox.org] >Sent: Thursday, May 20, 2004 9:24 AM >To: radiusext@ops.ietf.org >Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter > > >"Kuntal Chowdhury" wrote: >> Did you propose distribution of static shared secrets over RADIUS? > > No. We proposed distributing dynamic shared secrets, and a >method for updating shared secrets. > > See: http://homebase.htt-consult.com/sspp.html > > http://homebase.htt-consult.com/docs/radiusks.txt > > Alan DeKok. > > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:36:54 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2975@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , "Charles E. Perkins" Cc: radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 10:36:25 -0400 MIME-Version: 1.0 Content-Type: text/plain I think you got it wrong. The MN-HA shared secrets are not dynamically generated in the HAAA. At least I don't know of such a text in 3GPP2 standard. I think what we are discussing is purely key distribution issues. So, why don't we start the discussion about the need for a key distribution mechanism with RADIUS and see whether RADEXT can accommodate that? -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Thursday, May 20, 2004 9:30 AM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Charles E. Perkins; >Nakhjiri Madjid-MNAKHJI1 >Cc: radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Kuntal, > >As far as I understood, the secrets are hashed with MN-AAA keys. >Any key distribution method that happens on-line has to be >done this way. Also the secrets are only needed for the >duration of Mobile's visit to the foreign network. How is that >more long lived than a key established during IKE? > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Wednesday, May 19, 2004 5:18 PM >To: Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1 >Cc: radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Charlie, > >sending a users (static or long lived) shared-secret over the >wire opens up for attacks. If the MN-HA shared secret is >compromised, MIP4 will run into serious security issue. That's >why it is a bad idea. > >-Kuntal > >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Wednesday, May 19, 2004 5:11 PM >>To: Nakhjiri Madjid-MNAKHJI1 >>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >> >>Hello folks, >> >>Since I'm receiving these e-mails, perhaps someone could enlighten me: >> >>>2. The distribution of MN-HA shared-secret to the HA (from >>HAAAs) is a >>>bad practice. We are not doing that for MIP6 and we may fix that in a >>>bug fix release for MIP4. >>> >>> >>Why is this a bad idea? >> >>I thought it was pretty good, actually... >> >> >>Regards, >>Charlie P. >> > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:32:06 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC293D@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Charles E. Perkins" Cc: "Lila Madour (QA/EMC)" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter Date: Thu, 20 May 2004 10:31:18 -0400 MIME-Version: 1.0 Content-Type: text/plain Charlie, Essentially you are saying that sending shared secret from the location where it is securely stored to another device over RADIUS proxy chain is a good idea? -Kuntal >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 7:50 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; >radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP >support??: RADEXT WG Charter > > >Hello Kuntal, > >> Kuntal Chowdhury wrote: >> >>We cannot assume that the HA and the HAAA server SHALL always >be in the >>same administrative domain. >> >That means another solution is required for expanded >applicability. It doesn't mean that the offered solution is >inappropriate for its domain of applicability. > >> Moreover, for RADIUS, every proxy in the PATH will >>see the MN-HA shared secret. >> >> >Well, since the secret didn't exist at all anyway until the >AAAH created it, I don't see the big deal here. If there is >some worry, then: >(a) use a shorter lifetime and/or >(b) use another key when moving to another domain > >>Again, this issue should be discussed with security area folks. >> >> >They've looked at it pretty close a few dozen >times by now I reckon. > >Regards, >Charlie P. > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:30:33 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" , "Charles E. Perkins" , Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 09:30:07 -0500 MIME-Version: 1.0 Content-Type: text/plain Kuntal, As far as I understood, the secrets are hashed with MN-AAA keys. Any key distribution method that happens on-line has to be done this way. Also the secrets are only needed for the duration of Mobile's visit to the foreign network. How is that more long lived than a key established during IKE? Madjid -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: Wednesday, May 19, 2004 5:18 PM To: Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Charlie, sending a users (static or long lived) shared-secret over the wire opens up for attacks. If the MN-HA shared secret is compromised, MIP4 will run into serious security issue. That's why it is a bad idea. -Kuntal >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 5:11 PM >To: Nakhjiri Madjid-MNAKHJI1 >Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > > >Hello folks, > >Since I'm receiving these e-mails, perhaps someone could enlighten me: > >>2. The distribution of MN-HA shared-secret to the HA (from >HAAAs) is a >>bad practice. We are not doing that for MIP6 and we may fix that in a >>bug fix release for MIP4. >> >> >Why is this a bad idea? > >I thought it was pretty good, actually... > > >Regards, >Charlie P. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:26:25 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Lila Madour (QA/EMC)'" , "'Kuntal Chowdhury'" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 09:25:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I echo Kuntal's statement. The 3GPP2 standard that supports MIPv4 with RADIUS has been around since year 2000. I don't see the need to start MIPv4 specific RADIUS work in RADEXT group. Lila Madjid>> I am sorry, but I do. Just because an SDO has an SDO-specific solution does not mean IETF has to stop working on interoperability of its own protocols. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury Sent: Wednesday, May 19, 2004 5:14 PM To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter In 3GPP2 text: 1. There is no pre-shared secret between the MN and the FA, so let's not talk about it. 2. The distribution of MN-HA shared-secret to the HA (from HAAAs) is a bad practice. We are not doing that for MIP6 and we may fix that in a bug fix release for MIP4. 3. FA-HA IKE pre-shared key distribution is a generic issue. The same applies to any two tunnel end points that wish to use IKE and wish to acquire share-secret via AAA infrastructure. It is NOT a MIP4 issue. Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from 3GPP2's perspective. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Wednesday, May 19, 2004 3:18 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >I guess it is fare to say that whenever I see a VSA, I call it >proprietary! First the support for Mobile IP is not according >to the same model as Diameter, some keys are established using >direct IKE, others sent from AAAH. Second, whenever RADIUS is >used, VSAs are used. I have provided more details below. But >first I wanted to make a point and that is if one is to >support both RADIUS and Mobile IP, one is forced to use VSAs. >This leads to lack of interoperability. > >I looked very quickly through their documentations, >X.S0011-002-C and -005-C, which talk about Mobile IP and >RADIUS: From what I can understand, only the RFC 3012 >(challenge/ response) is supported, while the key management >is not supported. I can understand that since the key >management is not an RFC yet. So basically: > >1-No MN-FA (PDSN) security associations/ authentications are >discussed, and this means distribution of keys for these SAs >are not discussed either (this is part of my original concern >with RADIUS: No attributes for AAAH-FA interaction). > >2-FA-HA security associations are established directly through >IKE (either through certificates or through pre-shared secrets >that distributed from AAAH using VSAs (IKE Pre-shared secret >26/1, pre-shared secret 26/3, etc). > >3-MN-HA keys are distributed through VSAs again. > >Let me know if I missed something. > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 5:59 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >>I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. > >Could you elaborate on what you think is a proprietary way in >3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS >attributes. As I said, I am not against MIP4 specific RADEXT >work, but I don't feel it is needed, that's all. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 5:50 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >>Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Sure, I am not saying the draft does not work for RADIUS. >>What I am saying is that MIP WG goes as far as they can with >>MIP-AAA signaling as far as defining extensions for MIP. >>However FA-AAAH and AAAH-HA messaging is assumed to be out of >>scope and left for AAA protocol. >>Diameter comes from the other end and plugs the holes, while >>RADIUS doesn't. >> >>I always thought IETF designs for the Internet and IP, and >>other SDOs come to IETF to borrow those standards. Of course, >>when it does not exist or they don't have time to wait, they >>do it their own way and the fact that they designed VSA attest >>to the fact that it is not standardized by IETF. I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. Should we >>go to 3GPP2 for our RADIUS standards from now on? That said, I >>have nothing against 3GPP2 approaches, and I am guessing Tom >>and Pete had a hand in designing it, which means it is of high >>quality. But shouldn't we look at it and consider whether it >>will fit the mold for an IETF standard that can be applied to >>other instances. Maybe Tom and Pete know the history of why >>the RADIUS draft (I myself have not seen it) didn't make it. >> >>I ccd Charlie on this, to hear his opinion! >> >>Regards, >> >>Madjid >> >>-----Original Message----- >>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >>Sent: Tuesday, May 18, 2004 4:56 PM >>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >>agnostic i.e. it would work with both. I CCed Pete McCann and >>Tom Hiller for their comments on the AAA keys draft. >> >>For normal authentication and authorization of MIP sessions I >>think are fine. We have not felt the need to define new AVPs >>or VSAs yet to carry MIP4 credentials to/from RADIUS. However >>I won't be opposed to any work if other folks feel that we >>need to define something new. We need to be careful to NOT >>break existing 3GPP2 implementations that uses standard RADIUS >>attributes. >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 4:34 PM >>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi Kuntal, >>> >>>Thanks a lot for the 3gpp2 doc number. >>>3012 leaves a lot of details out. The MIP key mgmt drafts >covers some >>>more details, but still leave the AAA server to HA and FA messaging >>>out, specially when it comes to key distribution. I have not yet >>>completely read the Diameter-MIP draft yet, but it looks like it >>>defines AVPs and messages for that. >>> >>>AAA group seems to only be doing Diameter, so the RADIUS draft >>>probably went no where. >>> >>>Shouldn't this group provide attributes and specs for RADIUS? >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>>Sent: Tuesday, May 18, 2004 3:53 PM >>>To: radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>RFC3012 based CHAP style authentication for MN-AAA works fine with >>>MIPv4. 3GPP2 is using standard RADIUS attributes such as >>>CHAP-Challenge and CHAP-password for this purpose. There is a VSA >>>defined for carrying the HA address, but HoA is carried in the >>>framed-IP address attribute. >>> >>>For AAA key distribution for Mobile IPv4, I think AAA WG has/had a >>>draft on this. Not sure what happened to it. >>> >>>You can visit www.3gpp2.org for the relevant specification >>(X.S0011-C). >>> >>>-Kuntal >>> >>>>-----Original Message----- >>>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>>Sent: Tuesday, May 18, 2004 3:42 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>>> >>>> >>>>Hi, >>>> >>>>I am not sure if it is too late to have anything added to >>the charter >>>>and I don't know how much interest for Mobile IP exists in >>the group, >>>>but here is a RADIUS-Diameter question anyway: >>>> >>>>AAA WG has been working on providing specs and AVPs in Diameter for >>>>Mobile IP support: specifically on how to authenticate the >>>>registration requests and replies as well as how to do key >>>>distribution for establishing security associations between mobile >>>>nodes and mobility agents. RADIUS does not seem to provide anything >>>>for that, unless I missed something! >>>> >>>>It seems that 3GPP2 is doing its own thing (I personally >>haven't found >>>>the specs, so I appreciate it if somebody sends it to me). Is the >>>>ongoing opinion that people should use VSAs for that >>purpose? or there >>>>is just not enough interest for Mobile IP within RADIUS community? >>>> >>>>Thanks, >>>> >>>>Madjid >>>> >>>>-----Original Message----- >>>>From: owner-radiusext@ops.ietf.org >>>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>>Sent: Thursday, April 15, 2004 6:52 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADEXT WG Charter, Take 10 >>>> >>>> >>>>Just thought I'd post the most recent charter text, so that folks >>>>could have a last look at it. Based on the previous discussion, it >>>>did not appear that there was a concensus to change the focus to >>>>handling both RADIUS & Diameter in a single charter. >>>> >>>>------------------------------------------------------------ >--------- >>>>RADIUS Extensions Working Group (RADEXT) Charter >>>>Last Modified: 2004-04-12 >>>> >>>>Chair(s): >>>>David Nelson >>>>Bernard Aboba >>>> >>>>Operations and Management Area Director(s): >>>>David Kessens >>>>Bert Wijnen >>>> >>>>Operations and Management Area Advisor: >>>>David Kessens >>>> >>>>Technical Advisor: >>>>Paul Congdon >>>> >>>>Mailing Lists: >>>>General Discussion: radiusext@ops.ietf.org >>>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>>Archive: http://ops.ietf.org/lists/radiusext >>>> >>>>Description of Working Group: >>>> >>>>The RADIUS Extensions Working Group will focus on extensions to the >>>>RADIUS protocol required to enable its use in applications >>such as IP >>>>telephony and Local Area Network authentication, authorization and >>>>accounting. >>>> >>>>In order to ensure backward compatibility with existing RADIUS >>>>implementations, as well as compatibility between RADIUS and >>Diameter, >>>>the following restrictions are imposed on extensions >>considered by the >>>>RADEXT >>>>WG: >>>> >>>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>>RFCs, >>>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>>and 3580. >>>>- All RADIUS work MUST be compatible with equivalent facilities in >>>> Diameter. >>>>- The RADIUS maximum packet size (4K) will not be increased. >>>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>>> >>>>Work Items >>>> >>>>The immediate goals of the RADEXT working group are to address the >>>>following issues: >>>> >>>>- RADIUS design guidelines. This document will provide guidelines >>>> for design of RADIUS attributes, including discussion of the >>>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>>> document will also review RADIUS data types and associated >>>> backwards compatibility issues, and may address common >>>> RADIUS implementation errors and fixes. >>>> >>>>- Revised NAI specification. This document, known as "RFC 2486bis" >>>> will revise the NAI specification to provide more details on >>>> routing as well as handling internationalization. >>>> >>>>- Pre-paid support. Prepaid services are contemplated in a number >>>> of potential applications, including wireless LAN access and IP >>>> telephony. In order to enable support of pre-paid services in an >>>> interoperable way, the WG will provide definitions of the >>>> attributes required to support operator service models for >>>> pre-paid, as documented in liaison communications. >>>> This document will be compatible with Diameter Credit Control. >>>> >>>>- SIP support. RADIUS is currently used for SIP authentication, >>>> authorization and accounting. Standardization of these attributes >>>> will enable improved interoperability. >>>> >>>>- LAN attributes. New attributes have been proposed to >enable use of >>>> authentication, authorization and accounting in wired and >>>> wireless LANs. Standardization of these attributes will enable >>>> improved interoperability. >>>> >>>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >>and modest >>>> changes are required to address this issue. >>>> >>>>Goals and Milestones: >>>> >>>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>>Standard >>>> RFC. >>>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>>> >>>>Quality Control Plan >>>> >>>>In order to ensure quality of work: >>>> >>>>* This WG will not be chartered until sufficient resources can be >>>> demonstrated to be available to guarantee a high probability of >>>> success. This includes recruitment of a core of editors and >>>> reviewers with significant IETF experience and demonstrated time >>>> commitment. >>>> >>>>* All drafts will need to undergo review prior to acceptance >>>as WG work >>>> items, which includes demonstration that the drafts are backward >>>> compatible with RADIUS RFCs and are compatible with equivalent >>>> facilities in Diameter. Given the backwards compatibility >>>issues, no >>>> document including sub-attributes will be considered for >>publication >>>>as >>>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>>> translation work items are completed, analyzing the issues in >>>> a comprehensive way. >>>> >>>>* The WG will utilize an automated issue tracking system. >>>> >>>>* XML to RFC will be used in production of documents. This enables >>>> production of HTML and text files from a single source file as >>>> well as automated production of difference files. >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 14:19:21 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Thu, 20 May 2004 10:24:24 -0400 Message-Id: <20040520142424.B834A16CC4@mail.nitros9.org> "Kuntal Chowdhury" wrote: > Did you propose distribution of static shared secrets over RADIUS? No. We proposed distributing dynamic shared secrets, and a method for updating shared secrets. See: http://homebase.htt-consult.com/sspp.html http://homebase.htt-consult.com/docs/radiusks.txt Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 May 2004 00:10:02 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2494@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Alan DeKok , radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 20:09:38 -0400 MIME-Version: 1.0 Content-Type: text/plain >-----Original Message----- >From: Alan DeKok [mailto:aland@ox.org] >Sent: Wednesday, May 19, 2004 6:20 PM >To: radiusext@ops.ietf.org >Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter > > >"Kuntal Chowdhury" wrote: >> MN-HA shared secret can be changed every moment or may be static >> (other end of the spectrum). Distribution of static pre-configured >> keys (not derived) is not a good crypto practice. May be we >should ask >> security area experts to comment on key distribution. > > Robert Moskowitz & I proposed a key bootstrap & distribution >method for RADIUS clients (client kickstart). It's not >exactly the same thing, but it's related. > Did you propose distribution of static shared secrets over RADIUS? > Alan DeKok. > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 23:16:35 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC245A@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Lila Madour (QA/EMC)" , "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 19:16:15 -0400 MIME-Version: 1.0 Content-Type: text/plain We cannot assume that the HA and the HAAA server SHALL always be in the same administrative domain. Moreover, for RADIUS, every proxy in the PATH will see the MN-HA shared secret. Again, this issue should be discussed with security area folks. -Kuntal >-----Original Message----- >From: Lila Madour (QA/EMC) [mailto:lila.madour@ericsson.com] >Sent: Wednesday, May 19, 2004 6:08 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Charles E. Perkins >Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete >McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >If the AAA and the HA are in the same administrative domain, >and if we assume it is a secure link between the AAA and the >HA, the security issue of distributing the key from the AAAH >to the HA may not be critical. >Lila > >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >Sent: Wednesday, May 19, 2004 6:48 PM >To: Charles E. Perkins >Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete >McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Charlie, > >MN-HA shared secret can be changed every moment or may be >static (other end of the spectrum). Distribution of static >pre-configured keys (not derived) is not a good crypto >practice. May be we should ask security area experts to >comment on key distribution. > >-Kuntal > >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Wednesday, May 19, 2004 5:34 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >>Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete >>McCann; tom.hiller@lucent.com >>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >> >>Hello Kuntal, >> >>How long is too long? >> >>Doesn't it matter that the secret is passed in a >>way that protects it from onlookers? >> >>Regards, >>Charlie P. >> >> >>Kuntal Chowdhury wrote: >> >>>Charlie, >>> >>>sending a users (static or long lived) shared-secret over the wire >>>opens up for attacks. If the MN-HA shared secret is >compromised, MIP4 >>>will run into serious security issue. That's why it is a bad idea. >>> >>>-Kuntal >>> >>> >>> >>>>-----Original Message----- >>>>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>>>Sent: Wednesday, May 19, 2004 5:11 PM >>>>To: Nakhjiri Madjid-MNAKHJI1 >>>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >>>>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>>> >>>> >>>> >>>>Hello folks, >>>> >>>>Since I'm receiving these e-mails, perhaps someone could >>enlighten me: >>>> >>>> >>>> >>>>>2. The distribution of MN-HA shared-secret to the HA (from >>>>> >>>>> >>>>HAAAs) is a >>>> >>>> >>>>>bad practice. We are not doing that for MIP6 and we may fix >>that in a >>>>>bug fix release for MIP4. >>>>> >>>>> >>>>> >>>>> >>>>Why is this a bad idea? >>>> >>>>I thought it was pretty good, actually... >>>> >>>> >>>>Regards, >>>>Charlie P. >>>> >>>> >>>> >> >> > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 23:14:54 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 19:20:23 -0400 Message-Id: <20040519232023.C48FE16FD1@mail.nitros9.org> "Kuntal Chowdhury" wrote: > MN-HA shared secret can be changed every moment or may be static (other end > of the spectrum). Distribution of static pre-configured keys (not derived) > is not a good crypto practice. May be we should ask security area experts to > comment on key distribution. Robert Moskowitz & I proposed a key bootstrap & distribution method for RADIUS clients (client kickstart). It's not exactly the same thing, but it's related. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 23:10:32 +0000 Message-ID: From: "Lila Madour (QA/EMC)" To: "'Kuntal Chowdhury'" , "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 18:08:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" If the AAA and the HA are in the same administrative domain, and if we assume it is a secure link between the AAA and the HA, the security issue of distributing the key from the AAAH to the HA may not be critical. Lila -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury Sent: Wednesday, May 19, 2004 6:48 PM To: Charles E. Perkins Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Charlie, MN-HA shared secret can be changed every moment or may be static (other end of the spectrum). Distribution of static pre-configured keys (not derived) is not a good crypto practice. May be we should ask security area experts to comment on key distribution. -Kuntal >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 5:34 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete >McCann; tom.hiller@lucent.com >Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter > > > >Hello Kuntal, > >How long is too long? > >Doesn't it matter that the secret is passed in a >way that protects it from onlookers? > >Regards, >Charlie P. > > >Kuntal Chowdhury wrote: > >>Charlie, >> >>sending a users (static or long lived) shared-secret over the wire >>opens up for attacks. If the MN-HA shared secret is compromised, MIP4 >>will run into serious security issue. That's why it is a bad idea. >> >>-Kuntal >> >> >> >>>-----Original Message----- >>>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>>Sent: Wednesday, May 19, 2004 5:11 PM >>>To: Nakhjiri Madjid-MNAKHJI1 >>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >>>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>> >>>Hello folks, >>> >>>Since I'm receiving these e-mails, perhaps someone could >enlighten me: >>> >>> >>> >>>>2. The distribution of MN-HA shared-secret to the HA (from >>>> >>>> >>>HAAAs) is a >>> >>> >>>>bad practice. We are not doing that for MIP6 and we may fix >that in a >>>>bug fix release for MIP4. >>>> >>>> >>>> >>>> >>>Why is this a bad idea? >>> >>>I thought it was pretty good, actually... >>> >>> >>>Regards, >>>Charlie P. >>> >>> >>> > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 22:48:30 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2428@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 18:47:54 -0400 MIME-Version: 1.0 Content-Type: text/plain Charlie, MN-HA shared secret can be changed every moment or may be static (other end of the spectrum). Distribution of static pre-configured keys (not derived) is not a good crypto practice. May be we should ask security area experts to comment on key distribution. -Kuntal >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 5:34 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org; Pete >McCann; tom.hiller@lucent.com >Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter > > > >Hello Kuntal, > >How long is too long? > >Doesn't it matter that the secret is passed in a >way that protects it from onlookers? > >Regards, >Charlie P. > > >Kuntal Chowdhury wrote: > >>Charlie, >> >>sending a users (static or long lived) shared-secret over the wire >>opens up for attacks. If the MN-HA shared secret is compromised, MIP4 >>will run into serious security issue. That's why it is a bad idea. >> >>-Kuntal >> >> >> >>>-----Original Message----- >>>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>>Sent: Wednesday, May 19, 2004 5:11 PM >>>To: Nakhjiri Madjid-MNAKHJI1 >>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >>>radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>> >>>Hello folks, >>> >>>Since I'm receiving these e-mails, perhaps someone could >enlighten me: >>> >>> >>> >>>>2. The distribution of MN-HA shared-secret to the HA (from >>>> >>>> >>>HAAAs) is a >>> >>> >>>>bad practice. We are not doing that for MIP6 and we may fix >that in a >>>>bug fix release for MIP4. >>>> >>>> >>>> >>>> >>>Why is this a bad idea? >>> >>>I thought it was pretty good, actually... >>> >>> >>>Regards, >>>Charlie P. >>> >>> >>> > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 22:18:27 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC23BC@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Charles E. Perkins" , Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 18:18:11 -0400 MIME-Version: 1.0 Content-Type: text/plain Charlie, sending a users (static or long lived) shared-secret over the wire opens up for attacks. If the MN-HA shared secret is compromised, MIP4 will run into serious security issue. That's why it is a bad idea. -Kuntal >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Wednesday, May 19, 2004 5:11 PM >To: Nakhjiri Madjid-MNAKHJI1 >Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; >radiusext@ops.ietf.org; Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > > >Hello folks, > >Since I'm receiving these e-mails, perhaps someone could enlighten me: > >>2. The distribution of MN-HA shared-secret to the HA (from >HAAAs) is a >>bad practice. We are not doing that for MIP6 and we may fix that in a >>bug fix release for MIP4. >> >> >Why is this a bad idea? > >I thought it was pretty good, actually... > > >Regards, >Charlie P. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 22:16:47 +0000 Message-ID: From: "Lila Madour (QA/EMC)" To: "'Kuntal Chowdhury'" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 17:14:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I echo Kuntal's statement. The 3GPP2 standard that supports MIPv4 with RADIUS has been around since year 2000. I don't see the need to start MIPv4 specific RADIUS work in RADEXT group. Lila -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury Sent: Wednesday, May 19, 2004 5:14 PM To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter In 3GPP2 text: 1. There is no pre-shared secret between the MN and the FA, so let's not talk about it. 2. The distribution of MN-HA shared-secret to the HA (from HAAAs) is a bad practice. We are not doing that for MIP6 and we may fix that in a bug fix release for MIP4. 3. FA-HA IKE pre-shared key distribution is a generic issue. The same applies to any two tunnel end points that wish to use IKE and wish to acquire share-secret via AAA infrastructure. It is NOT a MIP4 issue. Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from 3GPP2's perspective. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Wednesday, May 19, 2004 3:18 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >I guess it is fare to say that whenever I see a VSA, I call it >proprietary! First the support for Mobile IP is not according >to the same model as Diameter, some keys are established using >direct IKE, others sent from AAAH. Second, whenever RADIUS is >used, VSAs are used. I have provided more details below. But >first I wanted to make a point and that is if one is to >support both RADIUS and Mobile IP, one is forced to use VSAs. >This leads to lack of interoperability. > >I looked very quickly through their documentations, >X.S0011-002-C and -005-C, which talk about Mobile IP and >RADIUS: From what I can understand, only the RFC 3012 >(challenge/ response) is supported, while the key management >is not supported. I can understand that since the key >management is not an RFC yet. So basically: > >1-No MN-FA (PDSN) security associations/ authentications are >discussed, and this means distribution of keys for these SAs >are not discussed either (this is part of my original concern >with RADIUS: No attributes for AAAH-FA interaction). > >2-FA-HA security associations are established directly through >IKE (either through certificates or through pre-shared secrets >that distributed from AAAH using VSAs (IKE Pre-shared secret >26/1, pre-shared secret 26/3, etc). > >3-MN-HA keys are distributed through VSAs again. > >Let me know if I missed something. > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 5:59 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >>I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. > >Could you elaborate on what you think is a proprietary way in >3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS >attributes. As I said, I am not against MIP4 specific RADEXT >work, but I don't feel it is needed, that's all. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 5:50 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >>Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Sure, I am not saying the draft does not work for RADIUS. >>What I am saying is that MIP WG goes as far as they can with >>MIP-AAA signaling as far as defining extensions for MIP. >>However FA-AAAH and AAAH-HA messaging is assumed to be out of >>scope and left for AAA protocol. >>Diameter comes from the other end and plugs the holes, while >>RADIUS doesn't. >> >>I always thought IETF designs for the Internet and IP, and >>other SDOs come to IETF to borrow those standards. Of course, >>when it does not exist or they don't have time to wait, they >>do it their own way and the fact that they designed VSA attest >>to the fact that it is not standardized by IETF. I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. Should we >>go to 3GPP2 for our RADIUS standards from now on? That said, I >>have nothing against 3GPP2 approaches, and I am guessing Tom >>and Pete had a hand in designing it, which means it is of high >>quality. But shouldn't we look at it and consider whether it >>will fit the mold for an IETF standard that can be applied to >>other instances. Maybe Tom and Pete know the history of why >>the RADIUS draft (I myself have not seen it) didn't make it. >> >>I ccd Charlie on this, to hear his opinion! >> >>Regards, >> >>Madjid >> >>-----Original Message----- >>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >>Sent: Tuesday, May 18, 2004 4:56 PM >>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >>agnostic i.e. it would work with both. I CCed Pete McCann and >>Tom Hiller for their comments on the AAA keys draft. >> >>For normal authentication and authorization of MIP sessions I >>think are fine. We have not felt the need to define new AVPs >>or VSAs yet to carry MIP4 credentials to/from RADIUS. However >>I won't be opposed to any work if other folks feel that we >>need to define something new. We need to be careful to NOT >>break existing 3GPP2 implementations that uses standard RADIUS >>attributes. >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 4:34 PM >>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi Kuntal, >>> >>>Thanks a lot for the 3gpp2 doc number. >>>3012 leaves a lot of details out. The MIP key mgmt drafts >covers some >>>more details, but still leave the AAA server to HA and FA messaging >>>out, specially when it comes to key distribution. I have not yet >>>completely read the Diameter-MIP draft yet, but it looks like it >>>defines AVPs and messages for that. >>> >>>AAA group seems to only be doing Diameter, so the RADIUS draft >>>probably went no where. >>> >>>Shouldn't this group provide attributes and specs for RADIUS? >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>>Sent: Tuesday, May 18, 2004 3:53 PM >>>To: radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>RFC3012 based CHAP style authentication for MN-AAA works fine with >>>MIPv4. 3GPP2 is using standard RADIUS attributes such as >>>CHAP-Challenge and CHAP-password for this purpose. There is a VSA >>>defined for carrying the HA address, but HoA is carried in the >>>framed-IP address attribute. >>> >>>For AAA key distribution for Mobile IPv4, I think AAA WG has/had a >>>draft on this. Not sure what happened to it. >>> >>>You can visit www.3gpp2.org for the relevant specification >>(X.S0011-C). >>> >>>-Kuntal >>> >>>>-----Original Message----- >>>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>>Sent: Tuesday, May 18, 2004 3:42 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>>> >>>> >>>>Hi, >>>> >>>>I am not sure if it is too late to have anything added to >>the charter >>>>and I don't know how much interest for Mobile IP exists in >>the group, >>>>but here is a RADIUS-Diameter question anyway: >>>> >>>>AAA WG has been working on providing specs and AVPs in Diameter for >>>>Mobile IP support: specifically on how to authenticate the >>>>registration requests and replies as well as how to do key >>>>distribution for establishing security associations between mobile >>>>nodes and mobility agents. RADIUS does not seem to provide anything >>>>for that, unless I missed something! >>>> >>>>It seems that 3GPP2 is doing its own thing (I personally >>haven't found >>>>the specs, so I appreciate it if somebody sends it to me). Is the >>>>ongoing opinion that people should use VSAs for that >>purpose? or there >>>>is just not enough interest for Mobile IP within RADIUS community? >>>> >>>>Thanks, >>>> >>>>Madjid >>>> >>>>-----Original Message----- >>>>From: owner-radiusext@ops.ietf.org >>>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>>Sent: Thursday, April 15, 2004 6:52 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADEXT WG Charter, Take 10 >>>> >>>> >>>>Just thought I'd post the most recent charter text, so that folks >>>>could have a last look at it. Based on the previous discussion, it >>>>did not appear that there was a concensus to change the focus to >>>>handling both RADIUS & Diameter in a single charter. >>>> >>>>------------------------------------------------------------ >--------- >>>>RADIUS Extensions Working Group (RADEXT) Charter >>>>Last Modified: 2004-04-12 >>>> >>>>Chair(s): >>>>David Nelson >>>>Bernard Aboba >>>> >>>>Operations and Management Area Director(s): >>>>David Kessens >>>>Bert Wijnen >>>> >>>>Operations and Management Area Advisor: >>>>David Kessens >>>> >>>>Technical Advisor: >>>>Paul Congdon >>>> >>>>Mailing Lists: >>>>General Discussion: radiusext@ops.ietf.org >>>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>>Archive: http://ops.ietf.org/lists/radiusext >>>> >>>>Description of Working Group: >>>> >>>>The RADIUS Extensions Working Group will focus on extensions to the >>>>RADIUS protocol required to enable its use in applications >>such as IP >>>>telephony and Local Area Network authentication, authorization and >>>>accounting. >>>> >>>>In order to ensure backward compatibility with existing RADIUS >>>>implementations, as well as compatibility between RADIUS and >>Diameter, >>>>the following restrictions are imposed on extensions >>considered by the >>>>RADEXT >>>>WG: >>>> >>>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>>RFCs, >>>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>>and 3580. >>>>- All RADIUS work MUST be compatible with equivalent facilities in >>>> Diameter. >>>>- The RADIUS maximum packet size (4K) will not be increased. >>>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>>> >>>>Work Items >>>> >>>>The immediate goals of the RADEXT working group are to address the >>>>following issues: >>>> >>>>- RADIUS design guidelines. This document will provide guidelines >>>> for design of RADIUS attributes, including discussion of the >>>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>>> document will also review RADIUS data types and associated >>>> backwards compatibility issues, and may address common >>>> RADIUS implementation errors and fixes. >>>> >>>>- Revised NAI specification. This document, known as "RFC 2486bis" >>>> will revise the NAI specification to provide more details on >>>> routing as well as handling internationalization. >>>> >>>>- Pre-paid support. Prepaid services are contemplated in a number >>>> of potential applications, including wireless LAN access and IP >>>> telephony. In order to enable support of pre-paid services in an >>>> interoperable way, the WG will provide definitions of the >>>> attributes required to support operator service models for >>>> pre-paid, as documented in liaison communications. >>>> This document will be compatible with Diameter Credit Control. >>>> >>>>- SIP support. RADIUS is currently used for SIP authentication, >>>> authorization and accounting. Standardization of these attributes >>>> will enable improved interoperability. >>>> >>>>- LAN attributes. New attributes have been proposed to >enable use of >>>> authentication, authorization and accounting in wired and >>>> wireless LANs. Standardization of these attributes will enable >>>> improved interoperability. >>>> >>>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >>and modest >>>> changes are required to address this issue. >>>> >>>>Goals and Milestones: >>>> >>>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>>Standard >>>> RFC. >>>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>>> >>>>Quality Control Plan >>>> >>>>In order to ensure quality of work: >>>> >>>>* This WG will not be chartered until sufficient resources can be >>>> demonstrated to be available to guarantee a high probability of >>>> success. This includes recruitment of a core of editors and >>>> reviewers with significant IETF experience and demonstrated time >>>> commitment. >>>> >>>>* All drafts will need to undergo review prior to acceptance >>>as WG work >>>> items, which includes demonstration that the drafts are backward >>>> compatible with RADIUS RFCs and are compatible with equivalent >>>> facilities in Diameter. Given the backwards compatibility >>>issues, no >>>> document including sub-attributes will be considered for >>publication >>>>as >>>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>>> translation work items are completed, analyzing the issues in >>>> a comprehensive way. >>>> >>>>* The WG will utilize an automated issue tracking system. >>>> >>>>* XML to RFC will be used in production of documents. This enables >>>> production of HTML and text files from a single source file as >>>> well as automated production of difference files. >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 22:02:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 18:01:57 -0400 Message-ID: Thread-Topic: RADIUS-Mobile IP support??: RADEXT WG Charter Thread-Index: AcQ97A601pj6k0aPSWKOqA/m1zlGmQAAB4RQ From: "Nelson, David" To: "Nakhjiri Madjid-MNAKHJI1" , "Kuntal Chowdhury" , Cc: "Pete McCann" , , "Charles E.Perkins" > I still have a question for the group and chairs? > Is the group saying: go to Diameter for those needs? or there is not > enough room in charter now? or people are not interested? or as Bernard > said the group only wants to deal with other SDOs? The charter is currently in IESG review. The announcement went out to the IETF-Announce list today. There is quite a bit of work on the charter now. Unless there is an urgent requirement from 3GPP or 3GPP2 for this work, or unless another IETF WG requests it, it would seem inadvisable to take on this additional work now. There is always the possibility of re-chartering after all (or most) of our current deliverables have been achieved. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 21:54:49 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 16:53:44 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kuntal, Please see inline responses! I still have a question for the group and chairs? Is the group saying: go to Diameter for those needs? or there is not enough room in charter now? or people are not interested? or as Bernard said the group only wants to deal with other SDOs? Madjid In 3GPP2 text: 1. There is no pre-shared secret between the MN and the FA, so let's not talk about it. Madjid>> I am not sure what you mean by "let's not talk about it". That is exactly the point, there is no pre-shared secret and it must be established. You can't ignore that problem. 2. The distribution of MN-HA shared-secret to the HA (from HAAAs) is a bad practice. We are not doing that for MIP6 and we may fix that in a bug fix release for MIP4. Madjid>> Bad practice or not, it is something that both MIPv4 and AAA are standardizing in their respective groups. And I don't know what you mean by "We"? You mean IETF, or 3GPP2 (I am not sure I care about the latter!) 3. FA-HA IKE pre-shared key distribution is a generic issue. The same applies to any two tunnel end points that wish to use IKE and wish to acquire share-secret via AAA infrastructure. It is NOT a MIP4 issue. Madjid>>Please look at MIP key management drafts. Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from 3GPP2's perspective. Madjid>>Thanks, But I still like to hear from the group and chairs? Is the group saying: go to Diameter for those needs? or there is not enough room in charter now? or people are not interested? which is it? The world does not just revolve around 3G! -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Wednesday, May 19, 2004 3:18 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >I guess it is fare to say that whenever I see a VSA, I call it >proprietary! First the support for Mobile IP is not according >to the same model as Diameter, some keys are established using >direct IKE, others sent from AAAH. Second, whenever RADIUS is >used, VSAs are used. I have provided more details below. But >first I wanted to make a point and that is if one is to >support both RADIUS and Mobile IP, one is forced to use VSAs. >This leads to lack of interoperability. > >I looked very quickly through their documentations, >X.S0011-002-C and -005-C, which talk about Mobile IP and >RADIUS: From what I can understand, only the RFC 3012 >(challenge/ response) is supported, while the key management >is not supported. I can understand that since the key >management is not an RFC yet. So basically: > >1-No MN-FA (PDSN) security associations/ authentications are >discussed, and this means distribution of keys for these SAs >are not discussed either (this is part of my original concern >with RADIUS: No attributes for AAAH-FA interaction). > >2-FA-HA security associations are established directly through >IKE (either through certificates or through pre-shared secrets >that distributed from AAAH using VSAs (IKE Pre-shared secret >26/1, pre-shared secret 26/3, etc). > >3-MN-HA keys are distributed through VSAs again. > >Let me know if I missed something. > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 5:59 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >>I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. > >Could you elaborate on what you think is a proprietary way in >3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS >attributes. As I said, I am not against MIP4 specific RADEXT >work, but I don't feel it is needed, that's all. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 5:50 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >>Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Sure, I am not saying the draft does not work for RADIUS. >>What I am saying is that MIP WG goes as far as they can with >>MIP-AAA signaling as far as defining extensions for MIP. >>However FA-AAAH and AAAH-HA messaging is assumed to be out of >>scope and left for AAA protocol. >>Diameter comes from the other end and plugs the holes, while >>RADIUS doesn't. >> >>I always thought IETF designs for the Internet and IP, and >>other SDOs come to IETF to borrow those standards. Of course, >>when it does not exist or they don't have time to wait, they >>do it their own way and the fact that they designed VSA attest >>to the fact that it is not standardized by IETF. I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. Should we >>go to 3GPP2 for our RADIUS standards from now on? That said, I >>have nothing against 3GPP2 approaches, and I am guessing Tom >>and Pete had a hand in designing it, which means it is of high >>quality. But shouldn't we look at it and consider whether it >>will fit the mold for an IETF standard that can be applied to >>other instances. Maybe Tom and Pete know the history of why >>the RADIUS draft (I myself have not seen it) didn't make it. >> >>I ccd Charlie on this, to hear his opinion! >> >>Regards, >> >>Madjid >> >>-----Original Message----- >>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >>Sent: Tuesday, May 18, 2004 4:56 PM >>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >>agnostic i.e. it would work with both. I CCed Pete McCann and >>Tom Hiller for their comments on the AAA keys draft. >> >>For normal authentication and authorization of MIP sessions I >>think are fine. We have not felt the need to define new AVPs >>or VSAs yet to carry MIP4 credentials to/from RADIUS. However >>I won't be opposed to any work if other folks feel that we >>need to define something new. We need to be careful to NOT >>break existing 3GPP2 implementations that uses standard RADIUS >>attributes. >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 4:34 PM >>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi Kuntal, >>> >>>Thanks a lot for the 3gpp2 doc number. >>>3012 leaves a lot of details out. The MIP key mgmt drafts >covers some >>>more details, but still leave the AAA server to HA and FA messaging >>>out, specially when it comes to key distribution. I have not yet >>>completely read the Diameter-MIP draft yet, but it looks like it >>>defines AVPs and messages for that. >>> >>>AAA group seems to only be doing Diameter, so the RADIUS draft >>>probably went no where. >>> >>>Shouldn't this group provide attributes and specs for RADIUS? >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>>Sent: Tuesday, May 18, 2004 3:53 PM >>>To: radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>RFC3012 based CHAP style authentication for MN-AAA works fine with >>>MIPv4. 3GPP2 is using standard RADIUS attributes such as >>>CHAP-Challenge and CHAP-password for this purpose. There is a VSA >>>defined for carrying the HA address, but HoA is carried in the >>>framed-IP address attribute. >>> >>>For AAA key distribution for Mobile IPv4, I think AAA WG has/had a >>>draft on this. Not sure what happened to it. >>> >>>You can visit www.3gpp2.org for the relevant specification >>(X.S0011-C). >>> >>>-Kuntal >>> >>>>-----Original Message----- >>>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>>Sent: Tuesday, May 18, 2004 3:42 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>>> >>>> >>>>Hi, >>>> >>>>I am not sure if it is too late to have anything added to >>the charter >>>>and I don't know how much interest for Mobile IP exists in >>the group, >>>>but here is a RADIUS-Diameter question anyway: >>>> >>>>AAA WG has been working on providing specs and AVPs in Diameter for >>>>Mobile IP support: specifically on how to authenticate the >>>>registration requests and replies as well as how to do key >>>>distribution for establishing security associations between mobile >>>>nodes and mobility agents. RADIUS does not seem to provide anything >>>>for that, unless I missed something! >>>> >>>>It seems that 3GPP2 is doing its own thing (I personally >>haven't found >>>>the specs, so I appreciate it if somebody sends it to me). Is the >>>>ongoing opinion that people should use VSAs for that >>purpose? or there >>>>is just not enough interest for Mobile IP within RADIUS community? >>>> >>>>Thanks, >>>> >>>>Madjid >>>> >>>>-----Original Message----- >>>>From: owner-radiusext@ops.ietf.org >>>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>>Sent: Thursday, April 15, 2004 6:52 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADEXT WG Charter, Take 10 >>>> >>>> >>>>Just thought I'd post the most recent charter text, so that folks >>>>could have a last look at it. Based on the previous discussion, it >>>>did not appear that there was a concensus to change the focus to >>>>handling both RADIUS & Diameter in a single charter. >>>> >>>>------------------------------------------------------------ >--------- >>>>RADIUS Extensions Working Group (RADEXT) Charter >>>>Last Modified: 2004-04-12 >>>> >>>>Chair(s): >>>>David Nelson >>>>Bernard Aboba >>>> >>>>Operations and Management Area Director(s): >>>>David Kessens >>>>Bert Wijnen >>>> >>>>Operations and Management Area Advisor: >>>>David Kessens >>>> >>>>Technical Advisor: >>>>Paul Congdon >>>> >>>>Mailing Lists: >>>>General Discussion: radiusext@ops.ietf.org >>>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>>Archive: http://ops.ietf.org/lists/radiusext >>>> >>>>Description of Working Group: >>>> >>>>The RADIUS Extensions Working Group will focus on extensions to the >>>>RADIUS protocol required to enable its use in applications >>such as IP >>>>telephony and Local Area Network authentication, authorization and >>>>accounting. >>>> >>>>In order to ensure backward compatibility with existing RADIUS >>>>implementations, as well as compatibility between RADIUS and >>Diameter, >>>>the following restrictions are imposed on extensions >>considered by the >>>>RADEXT >>>>WG: >>>> >>>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>>RFCs, >>>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>>and 3580. >>>>- All RADIUS work MUST be compatible with equivalent facilities in >>>> Diameter. >>>>- The RADIUS maximum packet size (4K) will not be increased. >>>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>>> >>>>Work Items >>>> >>>>The immediate goals of the RADEXT working group are to address the >>>>following issues: >>>> >>>>- RADIUS design guidelines. This document will provide guidelines >>>> for design of RADIUS attributes, including discussion of the >>>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>>> document will also review RADIUS data types and associated >>>> backwards compatibility issues, and may address common >>>> RADIUS implementation errors and fixes. >>>> >>>>- Revised NAI specification. This document, known as "RFC 2486bis" >>>> will revise the NAI specification to provide more details on >>>> routing as well as handling internationalization. >>>> >>>>- Pre-paid support. Prepaid services are contemplated in a number >>>> of potential applications, including wireless LAN access and IP >>>> telephony. In order to enable support of pre-paid services in an >>>> interoperable way, the WG will provide definitions of the >>>> attributes required to support operator service models for >>>> pre-paid, as documented in liaison communications. >>>> This document will be compatible with Diameter Credit Control. >>>> >>>>- SIP support. RADIUS is currently used for SIP authentication, >>>> authorization and accounting. Standardization of these attributes >>>> will enable improved interoperability. >>>> >>>>- LAN attributes. New attributes have been proposed to >enable use of >>>> authentication, authorization and accounting in wired and >>>> wireless LANs. Standardization of these attributes will enable >>>> improved interoperability. >>>> >>>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >>and modest >>>> changes are required to address this issue. >>>> >>>>Goals and Milestones: >>>> >>>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>>Standard >>>> RFC. >>>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>>> >>>>Quality Control Plan >>>> >>>>In order to ensure quality of work: >>>> >>>>* This WG will not be chartered until sufficient resources can be >>>> demonstrated to be available to guarantee a high probability of >>>> success. This includes recruitment of a core of editors and >>>> reviewers with significant IETF experience and demonstrated time >>>> commitment. >>>> >>>>* All drafts will need to undergo review prior to acceptance >>>as WG work >>>> items, which includes demonstration that the drafts are backward >>>> compatible with RADIUS RFCs and are compatible with equivalent >>>> facilities in Diameter. Given the backwards compatibility >>>issues, no >>>> document including sub-attributes will be considered for >>publication >>>>as >>>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>>> translation work items are completed, analyzing the issues in >>>> a comprehensive way. >>>> >>>>* The WG will utilize an automated issue tracking system. >>>> >>>>* XML to RFC will be used in production of documents. This enables >>>> production of HTML and text files from a single source file as >>>> well as automated production of difference files. >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 21:14:15 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92AC2249@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 17:13:41 -0400 MIME-Version: 1.0 Content-Type: text/plain In 3GPP2 text: 1. There is no pre-shared secret between the MN and the FA, so let's not talk about it. 2. The distribution of MN-HA shared-secret to the HA (from HAAAs) is a bad practice. We are not doing that for MIP6 and we may fix that in a bug fix release for MIP4. 3. FA-HA IKE pre-shared key distribution is a generic issue. The same applies to any two tunnel end points that wish to use IKE and wish to acquire share-secret via AAA infrastructure. It is NOT a MIP4 issue. Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from 3GPP2's perspective. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Wednesday, May 19, 2004 3:18 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >I guess it is fare to say that whenever I see a VSA, I call it >proprietary! First the support for Mobile IP is not according >to the same model as Diameter, some keys are established using >direct IKE, others sent from AAAH. Second, whenever RADIUS is >used, VSAs are used. I have provided more details below. But >first I wanted to make a point and that is if one is to >support both RADIUS and Mobile IP, one is forced to use VSAs. >This leads to lack of interoperability. > >I looked very quickly through their documentations, >X.S0011-002-C and -005-C, which talk about Mobile IP and >RADIUS: From what I can understand, only the RFC 3012 >(challenge/ response) is supported, while the key management >is not supported. I can understand that since the key >management is not an RFC yet. So basically: > >1-No MN-FA (PDSN) security associations/ authentications are >discussed, and this means distribution of keys for these SAs >are not discussed either (this is part of my original concern >with RADIUS: No attributes for AAAH-FA interaction). > >2-FA-HA security associations are established directly through >IKE (either through certificates or through pre-shared secrets >that distributed from AAAH using VSAs (IKE Pre-shared secret >26/1, pre-shared secret 26/3, etc). > >3-MN-HA keys are distributed through VSAs again. > >Let me know if I missed something. > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 5:59 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >>I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. > >Could you elaborate on what you think is a proprietary way in >3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS >attributes. As I said, I am not against MIP4 specific RADEXT >work, but I don't feel it is needed, that's all. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 5:50 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >>Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Sure, I am not saying the draft does not work for RADIUS. >>What I am saying is that MIP WG goes as far as they can with >>MIP-AAA signaling as far as defining extensions for MIP. >>However FA-AAAH and AAAH-HA messaging is assumed to be out of >>scope and left for AAA protocol. >>Diameter comes from the other end and plugs the holes, while >>RADIUS doesn't. >> >>I always thought IETF designs for the Internet and IP, and >>other SDOs come to IETF to borrow those standards. Of course, >>when it does not exist or they don't have time to wait, they >>do it their own way and the fact that they designed VSA attest >>to the fact that it is not standardized by IETF. I didn't >>think that IETF should stop its standardization process, in >>this case defining attributes for MIP the way Diameter did, >>just because 3GPP2 has a proprietary way to do it. Should we >>go to 3GPP2 for our RADIUS standards from now on? That said, I >>have nothing against 3GPP2 approaches, and I am guessing Tom >>and Pete had a hand in designing it, which means it is of high >>quality. But shouldn't we look at it and consider whether it >>will fit the mold for an IETF standard that can be applied to >>other instances. Maybe Tom and Pete know the history of why >>the RADIUS draft (I myself have not seen it) didn't make it. >> >>I ccd Charlie on this, to hear his opinion! >> >>Regards, >> >>Madjid >> >>-----Original Message----- >>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >>Sent: Tuesday, May 18, 2004 4:56 PM >>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >>Cc: Pete McCann; tom.hiller@lucent.com >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >>agnostic i.e. it would work with both. I CCed Pete McCann and >>Tom Hiller for their comments on the AAA keys draft. >> >>For normal authentication and authorization of MIP sessions I >>think are fine. We have not felt the need to define new AVPs >>or VSAs yet to carry MIP4 credentials to/from RADIUS. However >>I won't be opposed to any work if other folks feel that we >>need to define something new. We need to be careful to NOT >>break existing 3GPP2 implementations that uses standard RADIUS >>attributes. >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 4:34 PM >>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi Kuntal, >>> >>>Thanks a lot for the 3gpp2 doc number. >>>3012 leaves a lot of details out. The MIP key mgmt drafts >covers some >>>more details, but still leave the AAA server to HA and FA messaging >>>out, specially when it comes to key distribution. I have not yet >>>completely read the Diameter-MIP draft yet, but it looks like it >>>defines AVPs and messages for that. >>> >>>AAA group seems to only be doing Diameter, so the RADIUS draft >>>probably went no where. >>> >>>Shouldn't this group provide attributes and specs for RADIUS? >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>>Sent: Tuesday, May 18, 2004 3:53 PM >>>To: radiusext@ops.ietf.org >>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>RFC3012 based CHAP style authentication for MN-AAA works fine with >>>MIPv4. 3GPP2 is using standard RADIUS attributes such as >>>CHAP-Challenge and CHAP-password for this purpose. There is a VSA >>>defined for carrying the HA address, but HoA is carried in the >>>framed-IP address attribute. >>> >>>For AAA key distribution for Mobile IPv4, I think AAA WG has/had a >>>draft on this. Not sure what happened to it. >>> >>>You can visit www.3gpp2.org for the relevant specification >>(X.S0011-C). >>> >>>-Kuntal >>> >>>>-----Original Message----- >>>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>>Sent: Tuesday, May 18, 2004 3:42 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>>> >>>> >>>>Hi, >>>> >>>>I am not sure if it is too late to have anything added to >>the charter >>>>and I don't know how much interest for Mobile IP exists in >>the group, >>>>but here is a RADIUS-Diameter question anyway: >>>> >>>>AAA WG has been working on providing specs and AVPs in Diameter for >>>>Mobile IP support: specifically on how to authenticate the >>>>registration requests and replies as well as how to do key >>>>distribution for establishing security associations between mobile >>>>nodes and mobility agents. RADIUS does not seem to provide anything >>>>for that, unless I missed something! >>>> >>>>It seems that 3GPP2 is doing its own thing (I personally >>haven't found >>>>the specs, so I appreciate it if somebody sends it to me). Is the >>>>ongoing opinion that people should use VSAs for that >>purpose? or there >>>>is just not enough interest for Mobile IP within RADIUS community? >>>> >>>>Thanks, >>>> >>>>Madjid >>>> >>>>-----Original Message----- >>>>From: owner-radiusext@ops.ietf.org >>>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>>Sent: Thursday, April 15, 2004 6:52 PM >>>>To: radiusext@ops.ietf.org >>>>Subject: RADEXT WG Charter, Take 10 >>>> >>>> >>>>Just thought I'd post the most recent charter text, so that folks >>>>could have a last look at it. Based on the previous discussion, it >>>>did not appear that there was a concensus to change the focus to >>>>handling both RADIUS & Diameter in a single charter. >>>> >>>>------------------------------------------------------------ >--------- >>>>RADIUS Extensions Working Group (RADEXT) Charter >>>>Last Modified: 2004-04-12 >>>> >>>>Chair(s): >>>>David Nelson >>>>Bernard Aboba >>>> >>>>Operations and Management Area Director(s): >>>>David Kessens >>>>Bert Wijnen >>>> >>>>Operations and Management Area Advisor: >>>>David Kessens >>>> >>>>Technical Advisor: >>>>Paul Congdon >>>> >>>>Mailing Lists: >>>>General Discussion: radiusext@ops.ietf.org >>>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>>Archive: http://ops.ietf.org/lists/radiusext >>>> >>>>Description of Working Group: >>>> >>>>The RADIUS Extensions Working Group will focus on extensions to the >>>>RADIUS protocol required to enable its use in applications >>such as IP >>>>telephony and Local Area Network authentication, authorization and >>>>accounting. >>>> >>>>In order to ensure backward compatibility with existing RADIUS >>>>implementations, as well as compatibility between RADIUS and >>Diameter, >>>>the following restrictions are imposed on extensions >>considered by the >>>>RADEXT >>>>WG: >>>> >>>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>>RFCs, >>>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>>and 3580. >>>>- All RADIUS work MUST be compatible with equivalent facilities in >>>> Diameter. >>>>- The RADIUS maximum packet size (4K) will not be increased. >>>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>>> >>>>Work Items >>>> >>>>The immediate goals of the RADEXT working group are to address the >>>>following issues: >>>> >>>>- RADIUS design guidelines. This document will provide guidelines >>>> for design of RADIUS attributes, including discussion of the >>>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>>> document will also review RADIUS data types and associated >>>> backwards compatibility issues, and may address common >>>> RADIUS implementation errors and fixes. >>>> >>>>- Revised NAI specification. This document, known as "RFC 2486bis" >>>> will revise the NAI specification to provide more details on >>>> routing as well as handling internationalization. >>>> >>>>- Pre-paid support. Prepaid services are contemplated in a number >>>> of potential applications, including wireless LAN access and IP >>>> telephony. In order to enable support of pre-paid services in an >>>> interoperable way, the WG will provide definitions of the >>>> attributes required to support operator service models for >>>> pre-paid, as documented in liaison communications. >>>> This document will be compatible with Diameter Credit Control. >>>> >>>>- SIP support. RADIUS is currently used for SIP authentication, >>>> authorization and accounting. Standardization of these attributes >>>> will enable improved interoperability. >>>> >>>>- LAN attributes. New attributes have been proposed to >enable use of >>>> authentication, authorization and accounting in wired and >>>> wireless LANs. Standardization of these attributes will enable >>>> improved interoperability. >>>> >>>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >>and modest >>>> changes are required to address this issue. >>>> >>>>Goals and Milestones: >>>> >>>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>>Standard >>>> RFC. >>>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>>> >>>>Quality Control Plan >>>> >>>>In order to ensure quality of work: >>>> >>>>* This WG will not be chartered until sufficient resources can be >>>> demonstrated to be available to guarantee a high probability of >>>> success. This includes recruitment of a core of editors and >>>> reviewers with significant IETF experience and demonstrated time >>>> commitment. >>>> >>>>* All drafts will need to undergo review prior to acceptance >>>as WG work >>>> items, which includes demonstration that the drafts are backward >>>> compatible with RADIUS RFCs and are compatible with equivalent >>>> facilities in Diameter. Given the backwards compatibility >>>issues, no >>>> document including sub-attributes will be considered for >>publication >>>>as >>>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>>> translation work items are completed, analyzing the issues in >>>> a comprehensive way. >>>> >>>>* The WG will utilize an automated issue tracking system. >>>> >>>>* XML to RFC will be used in production of documents. This enables >>>> production of HTML and text files from a single source file as >>>> well as automated production of difference files. >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>>>-- >>>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 May 2004 20:24:39 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Wed, 19 May 2004 15:17:53 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kuntal, I guess it is fare to say that whenever I see a VSA, I call it proprietary! First the support for Mobile IP is not according to the same model as Diameter, some keys are established using direct IKE, others sent from AAAH. Second, whenever RADIUS is used, VSAs are used. I have provided more details below. But first I wanted to make a point and that is if one is to support both RADIUS and Mobile IP, one is forced to use VSAs. This leads to lack of interoperability. I looked very quickly through their documentations, X.S0011-002-C and -005-C, which talk about Mobile IP and RADIUS: >From what I can understand, only the RFC 3012 (challenge/ response) is supported, while the key management is not supported. I can understand that since the key management is not an RFC yet. So basically: 1-No MN-FA (PDSN) security associations/ authentications are discussed, and this means distribution of keys for these SAs are not discussed either (this is part of my original concern with RADIUS: No attributes for AAAH-FA interaction). 2-FA-HA security associations are established directly through IKE (either through certificates or through pre-shared secrets that distributed from AAAH using VSAs (IKE Pre-shared secret 26/1, pre-shared secret 26/3, etc). 3-MN-HA keys are distributed through VSAs again. Let me know if I missed something. Regards, Madjid -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: Tuesday, May 18, 2004 5:59 PM To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >I didn't >think that IETF should stop its standardization process, in >this case defining attributes for MIP the way Diameter did, >just because 3GPP2 has a proprietary way to do it. Could you elaborate on what you think is a proprietary way in 3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS attributes. As I said, I am not against MIP4 specific RADEXT work, but I don't feel it is needed, that's all. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 5:50 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Sure, I am not saying the draft does not work for RADIUS. >What I am saying is that MIP WG goes as far as they can with >MIP-AAA signaling as far as defining extensions for MIP. >However FA-AAAH and AAAH-HA messaging is assumed to be out of >scope and left for AAA protocol. >Diameter comes from the other end and plugs the holes, while >RADIUS doesn't. > >I always thought IETF designs for the Internet and IP, and >other SDOs come to IETF to borrow those standards. Of course, >when it does not exist or they don't have time to wait, they >do it their own way and the fact that they designed VSA attest >to the fact that it is not standardized by IETF. I didn't >think that IETF should stop its standardization process, in >this case defining attributes for MIP the way Diameter did, >just because 3GPP2 has a proprietary way to do it. Should we >go to 3GPP2 for our RADIUS standards from now on? That said, I >have nothing against 3GPP2 approaches, and I am guessing Tom >and Pete had a hand in designing it, which means it is of high >quality. But shouldn't we look at it and consider whether it >will fit the mold for an IETF standard that can be applied to >other instances. Maybe Tom and Pete know the history of why >the RADIUS draft (I myself have not seen it) didn't make it. > >I ccd Charlie on this, to hear his opinion! > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 4:56 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >agnostic i.e. it would work with both. I CCed Pete McCann and >Tom Hiller for their comments on the AAA keys draft. > >For normal authentication and authorization of MIP sessions I >think are fine. We have not felt the need to define new AVPs >or VSAs yet to carry MIP4 credentials to/from RADIUS. However >I won't be opposed to any work if other folks feel that we >need to define something new. We need to be careful to NOT >break existing 3GPP2 implementations that uses standard RADIUS >attributes. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 4:34 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Hi Kuntal, >> >>Thanks a lot for the 3gpp2 doc number. >>3012 leaves a lot of details out. The MIP key mgmt drafts >>covers some more details, but still leave the AAA server to HA >>and FA messaging out, specially when it comes to key >>distribution. I have not yet completely read the Diameter-MIP >>draft yet, but it looks like it defines AVPs and messages for that. >> >>AAA group seems to only be doing Diameter, so the RADIUS draft >>probably went no where. >> >>Shouldn't this group provide attributes and specs for RADIUS? >> >>Madjid >> >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org >>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>Sent: Tuesday, May 18, 2004 3:53 PM >>To: radiusext@ops.ietf.org >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>RFC3012 based CHAP style authentication for MN-AAA works fine >>with MIPv4. 3GPP2 is using standard RADIUS attributes such as >>CHAP-Challenge and CHAP-password for this purpose. There is a >>VSA defined for carrying the HA address, but HoA is carried in >>the framed-IP address attribute. >> >>For AAA key distribution for Mobile IPv4, I think AAA WG >>has/had a draft on this. Not sure what happened to it. >> >>You can visit www.3gpp2.org for the relevant specification >(X.S0011-C). >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 3:42 PM >>>To: radiusext@ops.ietf.org >>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi, >>> >>>I am not sure if it is too late to have anything added to >the charter >>>and I don't know how much interest for Mobile IP exists in >the group, >>>but here is a RADIUS-Diameter question anyway: >>> >>>AAA WG has been working on providing specs and AVPs in Diameter for >>>Mobile IP support: specifically on how to authenticate the >>>registration requests and replies as well as how to do key >>>distribution for establishing security associations between mobile >>>nodes and mobility agents. RADIUS does not seem to provide anything >>>for that, unless I missed something! >>> >>>It seems that 3GPP2 is doing its own thing (I personally >haven't found >>>the specs, so I appreciate it if somebody sends it to me). Is the >>>ongoing opinion that people should use VSAs for that >purpose? or there >>>is just not enough interest for Mobile IP within RADIUS community? >>> >>>Thanks, >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>Sent: Thursday, April 15, 2004 6:52 PM >>>To: radiusext@ops.ietf.org >>>Subject: RADEXT WG Charter, Take 10 >>> >>> >>>Just thought I'd post the most recent charter text, so that folks >>>could have a last look at it. Based on the previous discussion, it >>>did not appear that there was a concensus to change the focus to >>>handling both RADIUS & Diameter in a single charter. >>> >>>--------------------------------------------------------------------- >>>RADIUS Extensions Working Group (RADEXT) Charter >>>Last Modified: 2004-04-12 >>> >>>Chair(s): >>>David Nelson >>>Bernard Aboba >>> >>>Operations and Management Area Director(s): >>>David Kessens >>>Bert Wijnen >>> >>>Operations and Management Area Advisor: >>>David Kessens >>> >>>Technical Advisor: >>>Paul Congdon >>> >>>Mailing Lists: >>>General Discussion: radiusext@ops.ietf.org >>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>Archive: http://ops.ietf.org/lists/radiusext >>> >>>Description of Working Group: >>> >>>The RADIUS Extensions Working Group will focus on extensions to the >>>RADIUS protocol required to enable its use in applications >such as IP >>>telephony and Local Area Network authentication, authorization and >>>accounting. >>> >>>In order to ensure backward compatibility with existing RADIUS >>>implementations, as well as compatibility between RADIUS and >Diameter, >>>the following restrictions are imposed on extensions >considered by the >>>RADEXT >>>WG: >>> >>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>RFCs, >>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>and 3580. >>>- All RADIUS work MUST be compatible with equivalent facilities in >>> Diameter. >>>- The RADIUS maximum packet size (4K) will not be increased. >>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>> >>>Work Items >>> >>>The immediate goals of the RADEXT working group are to address the >>>following issues: >>> >>>- RADIUS design guidelines. This document will provide guidelines >>> for design of RADIUS attributes, including discussion of the >>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>> document will also review RADIUS data types and associated >>> backwards compatibility issues, and may address common >>> RADIUS implementation errors and fixes. >>> >>>- Revised NAI specification. This document, known as "RFC 2486bis" >>> will revise the NAI specification to provide more details on >>> routing as well as handling internationalization. >>> >>>- Pre-paid support. Prepaid services are contemplated in a number >>> of potential applications, including wireless LAN access and IP >>> telephony. In order to enable support of pre-paid services in an >>> interoperable way, the WG will provide definitions of the >>> attributes required to support operator service models for >>> pre-paid, as documented in liaison communications. >>> This document will be compatible with Diameter Credit Control. >>> >>>- SIP support. RADIUS is currently used for SIP authentication, >>> authorization and accounting. Standardization of these attributes >>> will enable improved interoperability. >>> >>>- LAN attributes. New attributes have been proposed to enable use of >>> authentication, authorization and accounting in wired and >>> wireless LANs. Standardization of these attributes will enable >>> improved interoperability. >>> >>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >and modest >>> changes are required to address this issue. >>> >>>Goals and Milestones: >>> >>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>Standard >>> RFC. >>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>> >>>Quality Control Plan >>> >>>In order to ensure quality of work: >>> >>>* This WG will not be chartered until sufficient resources can be >>> demonstrated to be available to guarantee a high probability of >>> success. This includes recruitment of a core of editors and >>> reviewers with significant IETF experience and demonstrated time >>> commitment. >>> >>>* All drafts will need to undergo review prior to acceptance >>as WG work >>> items, which includes demonstration that the drafts are backward >>> compatible with RADIUS RFCs and are compatible with equivalent >>> facilities in Diameter. Given the backwards compatibility >>issues, no >>> document including sub-attributes will be considered for >publication >>>as >>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>> translation work items are completed, analyzing the issues in >>> a comprehensive way. >>> >>>* The WG will utilize an automated issue tracking system. >>> >>>* XML to RFC will be used in production of documents. This enables >>> production of HTML and text files from a single source file as >>> well as automated production of difference files. >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> >>-- >>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 22:59:54 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92A195C4@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 18:59:18 -0400 MIME-Version: 1.0 Content-Type: text/plain >I didn't >think that IETF should stop its standardization process, in >this case defining attributes for MIP the way Diameter did, >just because 3GPP2 has a proprietary way to do it. Could you elaborate on what you think is a proprietary way in 3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS attributes. As I said, I am not against MIP4 specific RADEXT work, but I don't feel it is needed, that's all. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 5:50 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri >Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins' >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Sure, I am not saying the draft does not work for RADIUS. >What I am saying is that MIP WG goes as far as they can with >MIP-AAA signaling as far as defining extensions for MIP. >However FA-AAAH and AAAH-HA messaging is assumed to be out of >scope and left for AAA protocol. >Diameter comes from the other end and plugs the holes, while >RADIUS doesn't. > >I always thought IETF designs for the Internet and IP, and >other SDOs come to IETF to borrow those standards. Of course, >when it does not exist or they don't have time to wait, they >do it their own way and the fact that they designed VSA attest >to the fact that it is not standardized by IETF. I didn't >think that IETF should stop its standardization process, in >this case defining attributes for MIP the way Diameter did, >just because 3GPP2 has a proprietary way to do it. Should we >go to 3GPP2 for our RADIUS standards from now on? That said, I >have nothing against 3GPP2 approaches, and I am guessing Tom >and Pete had a hand in designing it, which means it is of high >quality. But shouldn't we look at it and consider whether it >will fit the mold for an IETF standard that can be applied to >other instances. Maybe Tom and Pete know the history of why >the RADIUS draft (I myself have not seen it) didn't make it. > >I ccd Charlie on this, to hear his opinion! > >Regards, > >Madjid > >-----Original Message----- >From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] >Sent: Tuesday, May 18, 2004 4:56 PM >To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org >Cc: Pete McCann; tom.hiller@lucent.com >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER >agnostic i.e. it would work with both. I CCed Pete McCann and >Tom Hiller for their comments on the AAA keys draft. > >For normal authentication and authorization of MIP sessions I >think are fine. We have not felt the need to define new AVPs >or VSAs yet to carry MIP4 credentials to/from RADIUS. However >I won't be opposed to any work if other folks feel that we >need to define something new. We need to be careful to NOT >break existing 3GPP2 implementations that uses standard RADIUS >attributes. > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 4:34 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Hi Kuntal, >> >>Thanks a lot for the 3gpp2 doc number. >>3012 leaves a lot of details out. The MIP key mgmt drafts >>covers some more details, but still leave the AAA server to HA >>and FA messaging out, specially when it comes to key >>distribution. I have not yet completely read the Diameter-MIP >>draft yet, but it looks like it defines AVPs and messages for that. >> >>AAA group seems to only be doing Diameter, so the RADIUS draft >>probably went no where. >> >>Shouldn't this group provide attributes and specs for RADIUS? >> >>Madjid >> >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org >>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >>Sent: Tuesday, May 18, 2004 3:53 PM >>To: radiusext@ops.ietf.org >>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>RFC3012 based CHAP style authentication for MN-AAA works fine >>with MIPv4. 3GPP2 is using standard RADIUS attributes such as >>CHAP-Challenge and CHAP-password for this purpose. There is a >>VSA defined for carrying the HA address, but HoA is carried in >>the framed-IP address attribute. >> >>For AAA key distribution for Mobile IPv4, I think AAA WG >>has/had a draft on this. Not sure what happened to it. >> >>You can visit www.3gpp2.org for the relevant specification >(X.S0011-C). >> >>-Kuntal >> >>>-----Original Message----- >>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>>Sent: Tuesday, May 18, 2004 3:42 PM >>>To: radiusext@ops.ietf.org >>>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >>> >>> >>>Hi, >>> >>>I am not sure if it is too late to have anything added to >the charter >>>and I don't know how much interest for Mobile IP exists in >the group, >>>but here is a RADIUS-Diameter question anyway: >>> >>>AAA WG has been working on providing specs and AVPs in Diameter for >>>Mobile IP support: specifically on how to authenticate the >>>registration requests and replies as well as how to do key >>>distribution for establishing security associations between mobile >>>nodes and mobility agents. RADIUS does not seem to provide anything >>>for that, unless I missed something! >>> >>>It seems that 3GPP2 is doing its own thing (I personally >haven't found >>>the specs, so I appreciate it if somebody sends it to me). Is the >>>ongoing opinion that people should use VSAs for that >purpose? or there >>>is just not enough interest for Mobile IP within RADIUS community? >>> >>>Thanks, >>> >>>Madjid >>> >>>-----Original Message----- >>>From: owner-radiusext@ops.ietf.org >>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>>Sent: Thursday, April 15, 2004 6:52 PM >>>To: radiusext@ops.ietf.org >>>Subject: RADEXT WG Charter, Take 10 >>> >>> >>>Just thought I'd post the most recent charter text, so that folks >>>could have a last look at it. Based on the previous discussion, it >>>did not appear that there was a concensus to change the focus to >>>handling both RADIUS & Diameter in a single charter. >>> >>>--------------------------------------------------------------------- >>>RADIUS Extensions Working Group (RADEXT) Charter >>>Last Modified: 2004-04-12 >>> >>>Chair(s): >>>David Nelson >>>Bernard Aboba >>> >>>Operations and Management Area Director(s): >>>David Kessens >>>Bert Wijnen >>> >>>Operations and Management Area Advisor: >>>David Kessens >>> >>>Technical Advisor: >>>Paul Congdon >>> >>>Mailing Lists: >>>General Discussion: radiusext@ops.ietf.org >>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>Archive: http://ops.ietf.org/lists/radiusext >>> >>>Description of Working Group: >>> >>>The RADIUS Extensions Working Group will focus on extensions to the >>>RADIUS protocol required to enable its use in applications >such as IP >>>telephony and Local Area Network authentication, authorization and >>>accounting. >>> >>>In order to ensure backward compatibility with existing RADIUS >>>implementations, as well as compatibility between RADIUS and >Diameter, >>>the following restrictions are imposed on extensions >considered by the >>>RADEXT >>>WG: >>> >>>- All RADIUS work MUST be backward compatible with existing RADIUS >>>RFCs, >>> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>>and 3580. >>>- All RADIUS work MUST be compatible with equivalent facilities in >>> Diameter. >>>- The RADIUS maximum packet size (4K) will not be increased. >>>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >>> >>>Work Items >>> >>>The immediate goals of the RADEXT working group are to address the >>>following issues: >>> >>>- RADIUS design guidelines. This document will provide guidelines >>> for design of RADIUS attributes, including discussion of the >>> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >>> document will also review RADIUS data types and associated >>> backwards compatibility issues, and may address common >>> RADIUS implementation errors and fixes. >>> >>>- Revised NAI specification. This document, known as "RFC 2486bis" >>> will revise the NAI specification to provide more details on >>> routing as well as handling internationalization. >>> >>>- Pre-paid support. Prepaid services are contemplated in a number >>> of potential applications, including wireless LAN access and IP >>> telephony. In order to enable support of pre-paid services in an >>> interoperable way, the WG will provide definitions of the >>> attributes required to support operator service models for >>> pre-paid, as documented in liaison communications. >>> This document will be compatible with Diameter Credit Control. >>> >>>- SIP support. RADIUS is currently used for SIP authentication, >>> authorization and accounting. Standardization of these attributes >>> will enable improved interoperability. >>> >>>- LAN attributes. New attributes have been proposed to enable use of >>> authentication, authorization and accounting in wired and >>> wireless LANs. Standardization of these attributes will enable >>> improved interoperability. >>> >>>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, >and modest >>> changes are required to address this issue. >>> >>>Goals and Milestones: >>> >>>Dec 04 Updated RADIUS MIBs submitted for publication. >>>Dec 04 RADIUS design guidelines submitted as an Informational RFC. >>>Dec 04 SIP RADIUS authentication draft submitted as a Proposed >>>Standard >>> RFC. >>>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>>05 LAN attributes draft submitted as a Proposed Standard RFC. >>>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >>> >>>Quality Control Plan >>> >>>In order to ensure quality of work: >>> >>>* This WG will not be chartered until sufficient resources can be >>> demonstrated to be available to guarantee a high probability of >>> success. This includes recruitment of a core of editors and >>> reviewers with significant IETF experience and demonstrated time >>> commitment. >>> >>>* All drafts will need to undergo review prior to acceptance >>as WG work >>> items, which includes demonstration that the drafts are backward >>> compatible with RADIUS RFCs and are compatible with equivalent >>> facilities in Diameter. Given the backwards compatibility >>issues, no >>> document including sub-attributes will be considered for >publication >>>as >>> an RFC before the RADIUS design guidelines and RADIUS/Diameter >>> translation work items are completed, analyzing the issues in >>> a comprehensive way. >>> >>>* The WG will utilize an automated issue tracking system. >>> >>>* XML to RFC will be used in production of documents. This enables >>> production of HTML and text files from a single source file as >>> well as automated production of difference files. >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>>-- >>>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >> >>-- >>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 22:50:21 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" , Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com, "'Charles E.Perkins'" Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 17:49:40 -0500 MIME-Version: 1.0 Content-Type: text/plain Sure, I am not saying the draft does not work for RADIUS. What I am saying is that MIP WG goes as far as they can with MIP-AAA signaling as far as defining extensions for MIP. However FA-AAAH and AAAH-HA messaging is assumed to be out of scope and left for AAA protocol. Diameter comes from the other end and plugs the holes, while RADIUS doesn't. I always thought IETF designs for the Internet and IP, and other SDOs come to IETF to borrow those standards. Of course, when it does not exist or they don't have time to wait, they do it their own way and the fact that they designed VSA attest to the fact that it is not standardized by IETF. I didn't think that IETF should stop its standardization process, in this case defining attributes for MIP the way Diameter did, just because 3GPP2 has a proprietary way to do it. Should we go to 3GPP2 for our RADIUS standards from now on? That said, I have nothing against 3GPP2 approaches, and I am guessing Tom and Pete had a hand in designing it, which means it is of high quality. But shouldn't we look at it and consider whether it will fit the mold for an IETF standard that can be applied to other instances. Maybe Tom and Pete know the history of why the RADIUS draft (I myself have not seen it) didn't make it. I ccd Charlie on this, to hear his opinion! Regards, Madjid -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: Tuesday, May 18, 2004 4:56 PM To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org Cc: Pete McCann; tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER agnostic i.e. it would work with both. I CCed Pete McCann and Tom Hiller for their comments on the AAA keys draft. For normal authentication and authorization of MIP sessions I think are fine. We have not felt the need to define new AVPs or VSAs yet to carry MIP4 credentials to/from RADIUS. However I won't be opposed to any work if other folks feel that we need to define something new. We need to be careful to NOT break existing 3GPP2 implementations that uses standard RADIUS attributes. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 4:34 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >Thanks a lot for the 3gpp2 doc number. >3012 leaves a lot of details out. The MIP key mgmt drafts >covers some more details, but still leave the AAA server to HA >and FA messaging out, specially when it comes to key >distribution. I have not yet completely read the Diameter-MIP >draft yet, but it looks like it defines AVPs and messages for that. > >AAA group seems to only be doing Diameter, so the RADIUS draft >probably went no where. > >Shouldn't this group provide attributes and specs for RADIUS? > >Madjid > >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >Sent: Tuesday, May 18, 2004 3:53 PM >To: radiusext@ops.ietf.org >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >RFC3012 based CHAP style authentication for MN-AAA works fine >with MIPv4. 3GPP2 is using standard RADIUS attributes such as >CHAP-Challenge and CHAP-password for this purpose. There is a >VSA defined for carrying the HA address, but HoA is carried in >the framed-IP address attribute. > >For AAA key distribution for Mobile IPv4, I think AAA WG >has/had a draft on this. Not sure what happened to it. > >You can visit www.3gpp2.org for the relevant specification (X.S0011-C). > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 3:42 PM >>To: radiusext@ops.ietf.org >>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Hi, >> >>I am not sure if it is too late to have anything added to the >>charter and I don't know how much interest for Mobile IP >>exists in the group, but here is a RADIUS-Diameter question anyway: >> >>AAA WG has been working on providing specs and AVPs in >>Diameter for Mobile IP support: specifically on how to >>authenticate the registration requests and replies as well as >>how to do key distribution for establishing security >>associations between mobile nodes and mobility agents. RADIUS >>does not seem to provide anything for that, unless I missed something! >> >>It seems that 3GPP2 is doing its own thing (I personally >>haven't found the specs, so I appreciate it if somebody sends >>it to me). Is the ongoing opinion that people should use VSAs >>for that purpose? or there is just not enough interest for >>Mobile IP within RADIUS community? >> >>Thanks, >> >>Madjid >> >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org >>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>Sent: Thursday, April 15, 2004 6:52 PM >>To: radiusext@ops.ietf.org >>Subject: RADEXT WG Charter, Take 10 >> >> >>Just thought I'd post the most recent charter text, so that >>folks could have a last look at it. Based on the previous >>discussion, it did not appear that there was a concensus to >>change the focus to handling both RADIUS & Diameter in a >>single charter. >> >>--------------------------------------------------------------------- >>RADIUS Extensions Working Group (RADEXT) Charter >>Last Modified: 2004-04-12 >> >>Chair(s): >>David Nelson >>Bernard Aboba >> >>Operations and Management Area Director(s): >>David Kessens >>Bert Wijnen >> >>Operations and Management Area Advisor: >>David Kessens >> >>Technical Advisor: >>Paul Congdon >> >>Mailing Lists: >>General Discussion: radiusext@ops.ietf.org >>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>Archive: http://ops.ietf.org/lists/radiusext >> >>Description of Working Group: >> >>The RADIUS Extensions Working Group will focus on extensions >>to the RADIUS protocol required to enable its use in >>applications such as IP telephony and Local Area Network >>authentication, authorization and accounting. >> >>In order to ensure backward compatibility with existing RADIUS >>implementations, as well as compatibility between RADIUS and >>Diameter, the following restrictions are imposed on extensions >>considered by the RADEXT >>WG: >> >>- All RADIUS work MUST be backward compatible with existing >>RADIUS RFCs, >> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>and 3580. >>- All RADIUS work MUST be compatible with equivalent facilities in >> Diameter. >>- The RADIUS maximum packet size (4K) will not be increased. >>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >> >>Work Items >> >>The immediate goals of the RADEXT working group are to address >>the following issues: >> >>- RADIUS design guidelines. This document will provide guidelines >> for design of RADIUS attributes, including discussion of the >> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >> document will also review RADIUS data types and associated >> backwards compatibility issues, and may address common >> RADIUS implementation errors and fixes. >> >>- Revised NAI specification. This document, known as "RFC 2486bis" >> will revise the NAI specification to provide more details on >> routing as well as handling internationalization. >> >>- Pre-paid support. Prepaid services are contemplated in a number >> of potential applications, including wireless LAN access and IP >> telephony. In order to enable support of pre-paid services in an >> interoperable way, the WG will provide definitions of the >> attributes required to support operator service models for >> pre-paid, as documented in liaison communications. >> This document will be compatible with Diameter Credit Control. >> >>- SIP support. RADIUS is currently used for SIP authentication, >> authorization and accounting. Standardization of these attributes >> will enable improved interoperability. >> >>- LAN attributes. New attributes have been proposed to enable use of >> authentication, authorization and accounting in wired and >> wireless LANs. Standardization of these attributes will enable >> improved interoperability. >> >>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest >> changes are required to address this issue. >> >>Goals and Milestones: >> >>Dec 04 Updated RADIUS MIBs submitted for publication. >>Dec 04 RADIUS design guidelines submitted as an Informational >>RFC. Dec 04 SIP RADIUS authentication draft submitted as a >>Proposed Standard >> RFC. >>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>05 LAN attributes draft submitted as a Proposed Standard RFC. >>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >> >>Quality Control Plan >> >>In order to ensure quality of work: >> >>* This WG will not be chartered until sufficient resources can be >> demonstrated to be available to guarantee a high probability of >> success. This includes recruitment of a core of editors and >> reviewers with significant IETF experience and demonstrated time >> commitment. >> >>* All drafts will need to undergo review prior to acceptance >as WG work >> items, which includes demonstration that the drafts are backward >> compatible with RADIUS RFCs and are compatible with equivalent >> facilities in Diameter. Given the backwards compatibility >issues, no >> document including sub-attributes will be considered for >>publication as >> an RFC before the RADIUS design guidelines and RADIUS/Diameter >> translation work items are completed, analyzing the issues in >> a comprehensive way. >> >>* The WG will utilize an automated issue tracking system. >> >>* XML to RFC will be used in production of documents. This enables >> production of HTML and text files from a single source file as >> well as automated production of difference files. >> >>-- >>to unsubscribe send a message to >>radiusext-request@ops.ietf.org with the word 'unsubscribe' in >>a single line as the message text body. >>archive: >> >>-- >>to unsubscribe send a message to >>radiusext-request@ops.ietf.org with the word 'unsubscribe' in >>a single line as the message text body. >>archive: >> > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 22:05:14 +0000 Date: Tue, 18 May 2004 15:08:18 -0700 (PDT) From: Bernard Aboba To: Kuntal Chowdhury cc: radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The RADEXT WG charter is based on work requested by SDOs (3GPP, 3GPP2, IEEE 802, GSMA, etc.) or by IETF WGs (SIPPING). So far we have no outstanding requests for RADIUS support for MIPv4. On Tue, 18 May 2004, Kuntal Chowdhury wrote: > I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER agnostic i.e. it > would work with both. I CCed Pete McCann and Tom Hiller for their comments > on the AAA keys draft. > > For normal authentication and authorization of MIP sessions I think are > fine. We have not felt the need to define new AVPs or VSAs yet to carry MIP4 > credentials to/from RADIUS. However I won't be opposed to any work if other > folks feel that we need to define something new. We need to be careful to > NOT break existing 3GPP2 implementations that uses standard RADIUS > attributes. > > -Kuntal -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 21:56:33 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92A194B6@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Nakhjiri Madjid-MNAKHJI1 , radiusext@ops.ietf.org Cc: Pete McCann , tom.hiller@lucent.com Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 17:56:01 -0400 MIME-Version: 1.0 Content-Type: text/plain I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER agnostic i.e. it would work with both. I CCed Pete McCann and Tom Hiller for their comments on the AAA keys draft. For normal authentication and authorization of MIP sessions I think are fine. We have not felt the need to define new AVPs or VSAs yet to carry MIP4 credentials to/from RADIUS. However I won't be opposed to any work if other folks feel that we need to define something new. We need to be careful to NOT break existing 3GPP2 implementations that uses standard RADIUS attributes. -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 4:34 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi Kuntal, > >Thanks a lot for the 3gpp2 doc number. >3012 leaves a lot of details out. The MIP key mgmt drafts >covers some more details, but still leave the AAA server to HA >and FA messaging out, specially when it comes to key >distribution. I have not yet completely read the Diameter-MIP >draft yet, but it looks like it defines AVPs and messages for that. > >AAA group seems to only be doing Diameter, so the RADIUS draft >probably went no where. > >Shouldn't this group provide attributes and specs for RADIUS? > >Madjid > >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury >Sent: Tuesday, May 18, 2004 3:53 PM >To: radiusext@ops.ietf.org >Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter > > >RFC3012 based CHAP style authentication for MN-AAA works fine >with MIPv4. 3GPP2 is using standard RADIUS attributes such as >CHAP-Challenge and CHAP-password for this purpose. There is a >VSA defined for carrying the HA address, but HoA is carried in >the framed-IP address attribute. > >For AAA key distribution for Mobile IPv4, I think AAA WG >has/had a draft on this. Not sure what happened to it. > >You can visit www.3gpp2.org for the relevant specification (X.S0011-C). > >-Kuntal > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, May 18, 2004 3:42 PM >>To: radiusext@ops.ietf.org >>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter >> >> >>Hi, >> >>I am not sure if it is too late to have anything added to the >>charter and I don't know how much interest for Mobile IP >>exists in the group, but here is a RADIUS-Diameter question anyway: >> >>AAA WG has been working on providing specs and AVPs in >>Diameter for Mobile IP support: specifically on how to >>authenticate the registration requests and replies as well as >>how to do key distribution for establishing security >>associations between mobile nodes and mobility agents. RADIUS >>does not seem to provide anything for that, unless I missed something! >> >>It seems that 3GPP2 is doing its own thing (I personally >>haven't found the specs, so I appreciate it if somebody sends >>it to me). Is the ongoing opinion that people should use VSAs >>for that purpose? or there is just not enough interest for >>Mobile IP within RADIUS community? >> >>Thanks, >> >>Madjid >> >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org >>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >>Sent: Thursday, April 15, 2004 6:52 PM >>To: radiusext@ops.ietf.org >>Subject: RADEXT WG Charter, Take 10 >> >> >>Just thought I'd post the most recent charter text, so that >>folks could have a last look at it. Based on the previous >>discussion, it did not appear that there was a concensus to >>change the focus to handling both RADIUS & Diameter in a >>single charter. >> >>--------------------------------------------------------------------- >>RADIUS Extensions Working Group (RADEXT) Charter >>Last Modified: 2004-04-12 >> >>Chair(s): >>David Nelson >>Bernard Aboba >> >>Operations and Management Area Director(s): >>David Kessens >>Bert Wijnen >> >>Operations and Management Area Advisor: >>David Kessens >> >>Technical Advisor: >>Paul Congdon >> >>Mailing Lists: >>General Discussion: radiusext@ops.ietf.org >>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>Archive: http://ops.ietf.org/lists/radiusext >> >>Description of Working Group: >> >>The RADIUS Extensions Working Group will focus on extensions >>to the RADIUS protocol required to enable its use in >>applications such as IP telephony and Local Area Network >>authentication, authorization and accounting. >> >>In order to ensure backward compatibility with existing RADIUS >>implementations, as well as compatibility between RADIUS and >>Diameter, the following restrictions are imposed on extensions >>considered by the RADEXT >>WG: >> >>- All RADIUS work MUST be backward compatible with existing >>RADIUS RFCs, >> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >>and 3580. >>- All RADIUS work MUST be compatible with equivalent facilities in >> Diameter. >>- The RADIUS maximum packet size (4K) will not be increased. >>- No new RADIUS transports (e.g. TCP, SCTP) will be defined. >> >>Work Items >> >>The immediate goals of the RADEXT working group are to address >>the following issues: >> >>- RADIUS design guidelines. This document will provide guidelines >> for design of RADIUS attributes, including discussion of the >> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This >> document will also review RADIUS data types and associated >> backwards compatibility issues, and may address common >> RADIUS implementation errors and fixes. >> >>- Revised NAI specification. This document, known as "RFC 2486bis" >> will revise the NAI specification to provide more details on >> routing as well as handling internationalization. >> >>- Pre-paid support. Prepaid services are contemplated in a number >> of potential applications, including wireless LAN access and IP >> telephony. In order to enable support of pre-paid services in an >> interoperable way, the WG will provide definitions of the >> attributes required to support operator service models for >> pre-paid, as documented in liaison communications. >> This document will be compatible with Diameter Credit Control. >> >>- SIP support. RADIUS is currently used for SIP authentication, >> authorization and accounting. Standardization of these attributes >> will enable improved interoperability. >> >>- LAN attributes. New attributes have been proposed to enable use of >> authentication, authorization and accounting in wired and >> wireless LANs. Standardization of these attributes will enable >> improved interoperability. >> >>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest >> changes are required to address this issue. >> >>Goals and Milestones: >> >>Dec 04 Updated RADIUS MIBs submitted for publication. >>Dec 04 RADIUS design guidelines submitted as an Informational >>RFC. Dec 04 SIP RADIUS authentication draft submitted as a >>Proposed Standard >> RFC. >>Feb 05 WLAN attributes draft submitted as a Proposed Standard >>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >>05 LAN attributes draft submitted as a Proposed Standard RFC. >>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. >> >>Quality Control Plan >> >>In order to ensure quality of work: >> >>* This WG will not be chartered until sufficient resources can be >> demonstrated to be available to guarantee a high probability of >> success. This includes recruitment of a core of editors and >> reviewers with significant IETF experience and demonstrated time >> commitment. >> >>* All drafts will need to undergo review prior to acceptance >as WG work >> items, which includes demonstration that the drafts are backward >> compatible with RADIUS RFCs and are compatible with equivalent >> facilities in Diameter. Given the backwards compatibility >issues, no >> document including sub-attributes will be considered for >>publication as >> an RFC before the RADIUS design guidelines and RADIUS/Diameter >> translation work items are completed, analyzing the issues in >> a comprehensive way. >> >>* The WG will utilize an automated issue tracking system. >> >>* XML to RFC will be used in production of documents. This enables >> production of HTML and text files from a single source file as >> well as automated production of difference files. >> >>-- >>to unsubscribe send a message to >>radiusext-request@ops.ietf.org with the word 'unsubscribe' in >>a single line as the message text body. >>archive: >> >>-- >>to unsubscribe send a message to >>radiusext-request@ops.ietf.org with the word 'unsubscribe' in >>a single line as the message text body. >>archive: >> > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 21:34:25 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kuntal Chowdhury'" , radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 16:34:10 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kuntal, Thanks a lot for the 3gpp2 doc number. 3012 leaves a lot of details out. The MIP key mgmt drafts covers some more details, but still leave the AAA server to HA and FA messaging out, specially when it comes to key distribution. I have not yet completely read the Diameter-MIP draft yet, but it looks like it defines AVPs and messages for that. AAA group seems to only be doing Diameter, so the RADIUS draft probably went no where. Shouldn't this group provide attributes and specs for RADIUS? Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury Sent: Tuesday, May 18, 2004 3:53 PM To: radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter RFC3012 based CHAP style authentication for MN-AAA works fine with MIPv4. 3GPP2 is using standard RADIUS attributes such as CHAP-Challenge and CHAP-password for this purpose. There is a VSA defined for carrying the HA address, but HoA is carried in the framed-IP address attribute. For AAA key distribution for Mobile IPv4, I think AAA WG has/had a draft on this. Not sure what happened to it. You can visit www.3gpp2.org for the relevant specification (X.S0011-C). -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 3:42 PM >To: radiusext@ops.ietf.org >Subject: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi, > >I am not sure if it is too late to have anything added to the >charter and I don't know how much interest for Mobile IP >exists in the group, but here is a RADIUS-Diameter question anyway: > >AAA WG has been working on providing specs and AVPs in >Diameter for Mobile IP support: specifically on how to >authenticate the registration requests and replies as well as >how to do key distribution for establishing security >associations between mobile nodes and mobility agents. RADIUS >does not seem to provide anything for that, unless I missed something! > >It seems that 3GPP2 is doing its own thing (I personally >haven't found the specs, so I appreciate it if somebody sends >it to me). Is the ongoing opinion that people should use VSAs >for that purpose? or there is just not enough interest for >Mobile IP within RADIUS community? > >Thanks, > >Madjid > >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >Sent: Thursday, April 15, 2004 6:52 PM >To: radiusext@ops.ietf.org >Subject: RADEXT WG Charter, Take 10 > > >Just thought I'd post the most recent charter text, so that >folks could have a last look at it. Based on the previous >discussion, it did not appear that there was a concensus to >change the focus to handling both RADIUS & Diameter in a >single charter. > >--------------------------------------------------------------------- >RADIUS Extensions Working Group (RADEXT) Charter >Last Modified: 2004-04-12 > >Chair(s): >David Nelson >Bernard Aboba > >Operations and Management Area Director(s): >David Kessens >Bert Wijnen > >Operations and Management Area Advisor: >David Kessens > >Technical Advisor: >Paul Congdon > >Mailing Lists: >General Discussion: radiusext@ops.ietf.org >To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >Archive: http://ops.ietf.org/lists/radiusext > >Description of Working Group: > >The RADIUS Extensions Working Group will focus on extensions >to the RADIUS protocol required to enable its use in >applications such as IP telephony and Local Area Network >authentication, authorization and accounting. > >In order to ensure backward compatibility with existing RADIUS >implementations, as well as compatibility between RADIUS and >Diameter, the following restrictions are imposed on extensions >considered by the RADEXT >WG: > >- All RADIUS work MUST be backward compatible with existing >RADIUS RFCs, > including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >and 3580. >- All RADIUS work MUST be compatible with equivalent facilities in > Diameter. >- The RADIUS maximum packet size (4K) will not be increased. >- No new RADIUS transports (e.g. TCP, SCTP) will be defined. > >Work Items > >The immediate goals of the RADEXT working group are to address >the following issues: > >- RADIUS design guidelines. This document will provide guidelines > for design of RADIUS attributes, including discussion of the > appropriate use of RADIUS SDO-Specific Attributes (SSAs). This > document will also review RADIUS data types and associated > backwards compatibility issues, and may address common > RADIUS implementation errors and fixes. > >- Revised NAI specification. This document, known as "RFC 2486bis" > will revise the NAI specification to provide more details on > routing as well as handling internationalization. > >- Pre-paid support. Prepaid services are contemplated in a number > of potential applications, including wireless LAN access and IP > telephony. In order to enable support of pre-paid services in an > interoperable way, the WG will provide definitions of the > attributes required to support operator service models for > pre-paid, as documented in liaison communications. > This document will be compatible with Diameter Credit Control. > >- SIP support. RADIUS is currently used for SIP authentication, > authorization and accounting. Standardization of these attributes > will enable improved interoperability. > >- LAN attributes. New attributes have been proposed to enable use of > authentication, authorization and accounting in wired and > wireless LANs. Standardization of these attributes will enable > improved interoperability. > >- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest > changes are required to address this issue. > >Goals and Milestones: > >Dec 04 Updated RADIUS MIBs submitted for publication. >Dec 04 RADIUS design guidelines submitted as an Informational >RFC. Dec 04 SIP RADIUS authentication draft submitted as a >Proposed Standard > RFC. >Feb 05 WLAN attributes draft submitted as a Proposed Standard >RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >05 LAN attributes draft submitted as a Proposed Standard RFC. >Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. > >Quality Control Plan > >In order to ensure quality of work: > >* This WG will not be chartered until sufficient resources can be > demonstrated to be available to guarantee a high probability of > success. This includes recruitment of a core of editors and > reviewers with significant IETF experience and demonstrated time > commitment. > >* All drafts will need to undergo review prior to acceptance as WG work > items, which includes demonstration that the drafts are backward > compatible with RADIUS RFCs and are compatible with equivalent > facilities in Diameter. Given the backwards compatibility issues, no > document including sub-attributes will be considered for >publication as > an RFC before the RADIUS design guidelines and RADIUS/Diameter > translation work items are completed, analyzing the issues in > a comprehensive way. > >* The WG will utilize an automated issue tracking system. > >* XML to RFC will be used in production of documents. This enables > production of HTML and text files from a single source file as > well as automated production of difference files. > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 20:53:20 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE92A192B5@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: radiusext@ops.ietf.org Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 16:52:51 -0400 MIME-Version: 1.0 Content-Type: text/plain RFC3012 based CHAP style authentication for MN-AAA works fine with MIPv4. 3GPP2 is using standard RADIUS attributes such as CHAP-Challenge and CHAP-password for this purpose. There is a VSA defined for carrying the HA address, but HoA is carried in the framed-IP address attribute. For AAA key distribution for Mobile IPv4, I think AAA WG has/had a draft on this. Not sure what happened to it. You can visit www.3gpp2.org for the relevant specification (X.S0011-C). -Kuntal >-----Original Message----- >From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >Sent: Tuesday, May 18, 2004 3:42 PM >To: radiusext@ops.ietf.org >Subject: RADIUS-Mobile IP support??: RADEXT WG Charter > > >Hi, > >I am not sure if it is too late to have anything added to the >charter and I don't know how much interest for Mobile IP >exists in the group, but here is a RADIUS-Diameter question anyway: > >AAA WG has been working on providing specs and AVPs in >Diameter for Mobile IP support: specifically on how to >authenticate the registration requests and replies as well as >how to do key distribution for establishing security >associations between mobile nodes and mobility agents. RADIUS >does not seem to provide anything for that, unless I missed something! > >It seems that 3GPP2 is doing its own thing (I personally >haven't found the specs, so I appreciate it if somebody sends >it to me). Is the ongoing opinion that people should use VSAs >for that purpose? or there is just not enough interest for >Mobile IP within RADIUS community? > >Thanks, > >Madjid > >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba >Sent: Thursday, April 15, 2004 6:52 PM >To: radiusext@ops.ietf.org >Subject: RADEXT WG Charter, Take 10 > > >Just thought I'd post the most recent charter text, so that >folks could have a last look at it. Based on the previous >discussion, it did not appear that there was a concensus to >change the focus to handling both RADIUS & Diameter in a >single charter. > >--------------------------------------------------------------------- >RADIUS Extensions Working Group (RADEXT) Charter >Last Modified: 2004-04-12 > >Chair(s): >David Nelson >Bernard Aboba > >Operations and Management Area Director(s): >David Kessens >Bert Wijnen > >Operations and Management Area Advisor: >David Kessens > >Technical Advisor: >Paul Congdon > >Mailing Lists: >General Discussion: radiusext@ops.ietf.org >To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >Archive: http://ops.ietf.org/lists/radiusext > >Description of Working Group: > >The RADIUS Extensions Working Group will focus on extensions >to the RADIUS protocol required to enable its use in >applications such as IP telephony and Local Area Network >authentication, authorization and accounting. > >In order to ensure backward compatibility with existing RADIUS >implementations, as well as compatibility between RADIUS and >Diameter, the following restrictions are imposed on extensions >considered by the RADEXT >WG: > >- All RADIUS work MUST be backward compatible with existing >RADIUS RFCs, > including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, >and 3580. >- All RADIUS work MUST be compatible with equivalent facilities in > Diameter. >- The RADIUS maximum packet size (4K) will not be increased. >- No new RADIUS transports (e.g. TCP, SCTP) will be defined. > >Work Items > >The immediate goals of the RADEXT working group are to address >the following issues: > >- RADIUS design guidelines. This document will provide guidelines > for design of RADIUS attributes, including discussion of the > appropriate use of RADIUS SDO-Specific Attributes (SSAs). This > document will also review RADIUS data types and associated > backwards compatibility issues, and may address common > RADIUS implementation errors and fixes. > >- Revised NAI specification. This document, known as "RFC 2486bis" > will revise the NAI specification to provide more details on > routing as well as handling internationalization. > >- Pre-paid support. Prepaid services are contemplated in a number > of potential applications, including wireless LAN access and IP > telephony. In order to enable support of pre-paid services in an > interoperable way, the WG will provide definitions of the > attributes required to support operator service models for > pre-paid, as documented in liaison communications. > This document will be compatible with Diameter Credit Control. > >- SIP support. RADIUS is currently used for SIP authentication, > authorization and accounting. Standardization of these attributes > will enable improved interoperability. > >- LAN attributes. New attributes have been proposed to enable use of > authentication, authorization and accounting in wired and > wireless LANs. Standardization of these attributes will enable > improved interoperability. > >- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest > changes are required to address this issue. > >Goals and Milestones: > >Dec 04 Updated RADIUS MIBs submitted for publication. >Dec 04 RADIUS design guidelines submitted as an Informational >RFC. Dec 04 SIP RADIUS authentication draft submitted as a >Proposed Standard > RFC. >Feb 05 WLAN attributes draft submitted as a Proposed Standard >RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec >05 LAN attributes draft submitted as a Proposed Standard RFC. >Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. > >Quality Control Plan > >In order to ensure quality of work: > >* This WG will not be chartered until sufficient resources can be > demonstrated to be available to guarantee a high probability of > success. This includes recruitment of a core of editors and > reviewers with significant IETF experience and demonstrated time > commitment. > >* All drafts will need to undergo review prior to acceptance as WG work > items, which includes demonstration that the drafts are backward > compatible with RADIUS RFCs and are compatible with equivalent > facilities in Diameter. Given the backwards compatibility issues, no > document including sub-attributes will be considered for >publication as > an RFC before the RADIUS design guidelines and RADIUS/Diameter > translation work items are completed, analyzing the issues in > a comprehensive way. > >* The WG will utilize an automated issue tracking system. > >* XML to RFC will be used in production of documents. This enables > production of HTML and text files from a single source file as > well as automated production of difference files. > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 May 2004 20:43:00 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: radiusext@ops.ietf.org Subject: RADIUS-Mobile IP support??: RADEXT WG Charter Date: Tue, 18 May 2004 15:42:02 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, I am not sure if it is too late to have anything added to the charter and I don't know how much interest for Mobile IP exists in the group, but here is a RADIUS-Diameter question anyway: AAA WG has been working on providing specs and AVPs in Diameter for Mobile IP support: specifically on how to authenticate the registration requests and replies as well as how to do key distribution for establishing security associations between mobile nodes and mobility agents. RADIUS does not seem to provide anything for that, unless I missed something! It seems that 3GPP2 is doing its own thing (I personally haven't found the specs, so I appreciate it if somebody sends it to me). Is the ongoing opinion that people should use VSAs for that purpose? or there is just not enough interest for Mobile IP within RADIUS community? Thanks, Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba Sent: Thursday, April 15, 2004 6:52 PM To: radiusext@ops.ietf.org Subject: RADEXT WG Charter, Take 10 Just thought I'd post the most recent charter text, so that folks could have a last look at it. Based on the previous discussion, it did not appear that there was a concensus to change the focus to handling both RADIUS & Diameter in a single charter. --------------------------------------------------------------------- RADIUS Extensions Working Group (RADEXT) Charter Last Modified: 2004-04-12 Chair(s): David Nelson Bernard Aboba Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe Archive: http://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. In order to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. - The RADIUS maximum packet size (4K) will not be increased. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes, including discussion of the appropriate use of RADIUS SDO-Specific Attributes (SSAs). This document will also review RADIUS data types and associated backwards compatibility issues, and may address common RADIUS implementation errors and fixes. - Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to provide more details on routing as well as handling internationalization. - Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will be compatible with Diameter Credit Control. - SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability. - LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. - RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest changes are required to address this issue. Goals and Milestones: Dec 04 Updated RADIUS MIBs submitted for publication. Dec 04 RADIUS design guidelines submitted as an Informational RFC. Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard RFC. Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec 05 LAN attributes draft submitted as a Proposed Standard RFC. Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. Quality Control Plan In order to ensure quality of work: * This WG will not be chartered until sufficient resources can be demonstrated to be available to guarantee a high probability of success. This includes recruitment of a core of editors and reviewers with significant IETF experience and demonstrated time commitment. * All drafts will need to undergo review prior to acceptance as WG work items, which includes demonstration that the drafts are backward compatible with RADIUS RFCs and are compatible with equivalent facilities in Diameter. Given the backwards compatibility issues, no document including sub-attributes will be considered for publication as an RFC before the RADIUS design guidelines and RADIUS/Diameter translation work items are completed, analyzing the issues in a comprehensive way. * The WG will utilize an automated issue tracking system. * XML to RFC will be used in production of documents. This enables production of HTML and text files from a single source file as well as automated production of difference files. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 12 May 2004 00:47:20 +0000 Date: Tue, 11 May 2004 17:50:43 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for Agenda Items for IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In order to submit a schedule request for RADEXT for IETF 60, we now have to submit an Agenda. So consider this a call for agenda items. Please send mail to me or David, letting us know: a. The name of the draft you wish to present. b. Whether you intend to rev the draft by IETF 60. c. How much time you need. d. Whether this is a charter item (charter items get priority). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 10 May 2004 14:33:37 +0000 Date: Mon, 10 May 2004 07:36:55 -0700 (PDT) From: Bernard Aboba To: stefaan.de_cnodder@alcatel.be cc: radiusext@ops.ietf.org Subject: Re: MIB for RFC3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Only an update for IPv6 is in the charter currently. To add a MIB, there needs to be interest from multiple parties in implementing it. On Mon, 10 May 2004 stefaan.de_cnodder@alcatel.be wrote: > > Hi, > > There are 2 new drafts describing a MIB for dynamic authorization > clients and servers (RFC 3576) available at: > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-00.txt > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-00.txt > > All comments are welcome. > > The charter says that all work has to be compatible with RFC 3576 > and that MIB updates are also part of the charter. Does this mean > that these drafts are also in scope of the charter after all it > completes the existing MIBs in RFC2618-2621, or are only the IPv6 > updates without a full revision of the current MIBs the scope of the > charter? > > thanks, > > Stefaan > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 10 May 2004 09:49:05 +0000 Message-ID: <409F4FD6.FC83A201@alcatel.be> Date: Mon, 10 May 2004 11:48:06 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: MIB for RFC3576 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, There are 2 new drafts describing a MIB for dynamic authorization clients and servers (RFC 3576) available at: http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-00.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-00.txt All comments are welcome. The charter says that all work has to be compatible with RFC 3576 and that MIB updates are also part of the charter. Does this mean that these drafts are also in scope of the charter after all it completes the existing MIBs in RFC2618-2621, or are only the IPv6 updates without a full revision of the current MIBs the scope of the charter? thanks, Stefaan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 20:22:42 +0000 Message-Id: <4.3.2.7.2.20040507131723.02a81a20@franklin.cisco.com> Date: Fri, 07 May 2004 13:22:50 -0700 To: "Nelson, David" , From: Parviz Yegani Subject: RE: Meeting at IETF 60 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, David, At 04:13 PM 5/7/2004 -0400, Nelson, David wrote: >Farid writes... > > > I agree that we should have a meeting at IETF-60. > > It is nice to know the chair's thought on this. > >I have inquired, off-list, as to the likelihood of having an IESG-approved >charter in time to request a WG meeting. Otherwise, we could request a >second BOF. Hope we can have a WG meeting instead of having yet another BOF. When do you expect to hear from IESG? -Parviz >-- Dave > > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 20:16:36 +0000 Message-Id: <4.3.2.7.2.20040507131351.02a71978@franklin.cisco.com> Date: Fri, 07 May 2004 13:16:50 -0700 To: "Adrangi, Farid" , "Avi Lior" , From: Parviz Yegani Subject: RE: Meeting at IETF 60 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_69462121==_.ALT" --=====================_69462121==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Avi, Farid, Good idea. I'll be there and can attend. -Parviz At 01:08 PM 5/7/2004 -0700, Adrangi, Farid wrote: >Hi Avi, >it is great that you bring it up now as we don't want to repeat the same >fiasco prior to the last IETF meeting! I agree that we should have a >meeting at IETF-60. It is nice to know the chair's thought on this. >BR, >Farid >-----Original Message----- >From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] >On Behalf Of Avi Lior >Sent: Friday, May 07, 2004 10:28 AM >To: radiusext@ops.ietf.org >Subject: Meeting at IETF 60 > >Hi All, > >I would like to propose that we have a meeting at IETF-60. > >Avi > --=====================_69462121==_.ALT Content-Type: text/html; charset="us-ascii" Avi, Farid,

Good idea. I'll be there and can attend.

-Parviz

At 01:08 PM 5/7/2004 -0700, Adrangi, Farid wrote:
Hi Avi,
it is great that you bring it up now as we don't want to repeat the same fiasco prior to the last IETF meeting!  I agree that we should have a meeting at IETF-60.  It is nice to know the chair's thought on this.
BR,
Farid
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
Sent: Friday, May 07, 2004 10:28 AM
To: radiusext@ops.ietf.org
Subject: Meeting at IETF 60
Hi All,
 
I would like to propose that we have a meeting at IETF-60.
 
Avi
 
--=====================_69462121==_.ALT-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 20:13:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Meeting at IETF 60 Date: Fri, 7 May 2004 16:13:12 -0400 Message-ID: Thread-Topic: Meeting at IETF 60 Thread-Index: AcQ0WMBXdiJ3kpTSRNeMxCvlgtdnJwAFiNKQAAAZ7YA= From: "Nelson, David" To: Farid writes... > I agree that we should have a meeting at IETF-60.=A0=20 > It is nice to know the chair's thought on this. I have inquired, off-list, as to the likelihood of having an = IESG-approved charter in time to request a WG meeting. Otherwise, we = could request a second BOF. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 20:08:25 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4346F.00FA4D9C" Subject: RE: Meeting at IETF 60 Date: Fri, 7 May 2004 13:08:03 -0700 Message-ID: Thread-Topic: Meeting at IETF 60 Thread-Index: AcQ0WMBXdiJ3kpTSRNeMxCvlgtdnJwAFiNKQ From: "Adrangi, Farid" To: "Avi Lior" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4346F.00FA4D9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avi, it is great that you bring it up now as we don't want to repeat the same fiasco prior to the last IETF meeting! I agree that we should have a meeting at IETF-60. It is nice to know the chair's thought on this. BR, Farid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Friday, May 07, 2004 10:28 AM To: radiusext@ops.ietf.org Subject: Meeting at IETF 60 =09 =09 Hi All, =20 I would like to propose that we have a meeting at IETF-60. =20 Avi =20 ------_=_NextPart_001_01C4346F.00FA4D9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Avi,
it is=20 great that you bring it up now as we don't want to repeat the same = fiasco prior=20 to the last IETF meeting!  I agree that we should have a meeting at = IETF-60.  It is nice to know the chair's thought on=20 this.
BR,
Farid
-----Original Message-----
From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Avi Lior
Sent: Friday, May 07, 2004 10:28=20 AM
To: radiusext@ops.ietf.org
Subject: Meeting at = IETF=20 60

Hi=20 All,
 
I=20 would like to propose that we have a meeting at = IETF-60.
 
Avi
 
=00 ------_=_NextPart_001_01C4346F.00FA4D9C-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 20:00:24 +0000 From: "Ed Van Horne" To: "'Avi Lior'" , Subject: RE: Meeting at IETF 60 Date: Fri, 7 May 2004 12:59:55 -0700 Organization: Cisco Systems Message-ID: <039c01c4346d$de599930$7d696540@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039D_01C43433.31FAC130" This is a multi-part message in MIME format. ------=_NextPart_000_039D_01C43433.31FAC130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I can be there, since I live in San Diego. Ed Ed Van Horne NMTG - San Diego Cisco Systems 10935 Vista Sorrento Parkway San Diego, CA 92130 858.526.1152 P.S.: What's up with IETF? We meet in Minneapolis in November and San Diego in August? I would have done it the other way around. ;-) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Friday, May 07, 2004 10:28 AM To: radiusext@ops.ietf.org Subject: Meeting at IETF 60 Hi All, I would like to propose that we have a meeting at IETF-60. Avi ------=_NextPart_000_039D_01C43433.31FAC130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I can=20 be there, since I live in San Diego.
 
Ed
 
Ed=20 Van Horne
NMTG - San=20 Diego
Cisco=20 Systems
10935 Vista=20 Sorrento Parkway
San=20 Diego, CA 92130
858.526.1152
 
P.S.: What's up with IETF? We meet in Minneapolis in November = and San=20 Diego in August? I would have done it the other way around.=20 ;-)
-----Original Message-----
From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Avi Lior
Sent: Friday, May 07, 2004 10:28=20 AM
To: radiusext@ops.ietf.org
Subject: Meeting at = IETF=20 60

Hi=20 All,
 
I=20 would like to propose that we have a meeting at = IETF-60.
 
Avi
 
------=_NextPart_000_039D_01C43433.31FAC130-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 May 2004 17:28:21 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Meeting at IETF 60 Date: Fri, 7 May 2004 13:27:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43458.A0D0C760" 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_01C43458.A0D0C760 Content-Type: text/plain Hi All, I would like to propose that we have a meeting at IETF-60. Avi ------_=_NextPart_001_01C43458.A0D0C760 Content-Type: text/html Message
Hi All,
 
I would like to propose that we have a meeting at IETF-60.
 
Avi
 
------_=_NextPart_001_01C43458.A0D0C760-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 06 May 2004 08:30:19 +0000 Message-ID: <4099F772.69D3473D@alcatel.be> Date: Thu, 06 May 2004 10:29:38 +0200 From: Nagi Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: "Nelson, David" CC: radiusext@ops.ietf.org Subject: Re: authorization of sub-sessions Content-Type: multipart/alternative; boundary="------------34BBBC19491C8CC0AF601F36" --------------34BBBC19491C8CC0AF601F36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kuntal, David and all, The base RFCs(RFC-2865 and RFC-2866) support a user having multiple sessions. See the definition of "session" below. Session: Each service provided by the NAS to a dial-in user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. *A user may have multiple sessions* in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record with its own Acct-Session-Id. Accounting seems to be OK: It believe that handling multiple sessions accounting is clearly supported by the RFC-2866. i.e., each susession will have its own accounting session ID. Also it appears to me that Acct-Multi-Session-Id is also used in conjunction with Accounting session ID to group the same user accounting. Though I'm not sure of the real intention of introducing Acct-Multi-Session-Id. See the definition of Acct-Multi-Session-Id. " This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id". Authentication also is basically ok After a user is authenticated, if the user wants to start a new subsession, he needs a re-authorization but not re-authentication. Though the RFC-2865 doesn't restrict having mutiple subsessions, it doesn't describe either how to handle subsessions. IMO, we need two things for re-authorization: a. Sending an access-request that clearly say this is an "Authorize-only" request but not a new authentication request. b. Attributes that describe what type of service is needed for the new subsession. Depending on the application new attributes can be added. The solution for (a) could be to use the Access request with the Service Type "Authorize-Only" which is defined in RFC-3576 already. regards Nagi. "Nelson, David" wrote: > Posted on behalf of Kuntal Chowdhury: > > >Hi all, > > > >During a recent 3GPP2-IETF co-ordination call the issue of > >authorization of multiple auxiliary sub-sessions under a PPP > >session came up. In 3GPP2 these sub sessions (termed auxiliary > >service instance) are initiated to support applications that > >need special treatments e.g. better than best effort QoS, > >header compression etc. Today, these sub sessions are not > >authorized using RADIUS messages (AR/AA). However, there are > >special accounting needs for these sub sessions i.e. separate > >accounting buckets are maintained for each of these sub > >sessions in the NAS. > > > >The intent of posting this message here is to initiate some > >discussion on sub sessions and possible RADIUS interaction. > > > >What would be the proper way to deal with these sub sessions? > >Do we need to define RADIUS procedures to handle auth and > >accounting of these sub sessions? > >Is there a possible link between the sub sessions and the need > >for sub types? Does the current (agreed) charter for RADEXT > >cover such a thing? > > > >-Kuntal > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --------------34BBBC19491C8CC0AF601F36 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kuntal, David and all,

The base RFCs(RFC-2865 and RFC-2866) support a user having multiple sessions. See the definition of "session" below.
 

Session:
             Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  *A user may have multiple sessions* in parallel or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record with
             its own Acct-Session-Id.

Accounting seems to be OK:
 

It believe that handling multiple sessions accounting is clearly supported by the RFC-2866. i.e., each susession will have its own accounting session ID.  Also it appears to me that Acct-Multi-Session-Id is also used in conjunction with Accounting session ID to group the same user accounting.  Though I'm not sure of the real intention of introducing Acct-Multi-Session-Id.

See the definition of Acct-Multi-Session-Id.

" This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id".

Authentication also is basically ok
 

After a user is authenticated, if the user wants to start a new subsession, he needs a re-authorization but not re-authentication. Though the RFC-2865 doesn't restrict having mutiple subsessions, it doesn't describe either how to handle subsessions.

IMO, we need two things for re-authorization:

a. Sending an access-request that clearly say this is an "Authorize-only" request but not a new authentication request.
b.  Attributes that describe what type of service is needed for the new subsession.  Depending on the application
    new attributes can be added.
 

The solution for (a) could be to use the Access request with the Service Type "Authorize-Only" which is defined in RFC-3576 already.

regards
Nagi.
 
 
 

"Nelson, David" wrote:

Posted on behalf of Kuntal Chowdhury:

>Hi all,
>
>During a recent 3GPP2-IETF co-ordination call the issue of
>authorization of multiple auxiliary sub-sessions under a PPP
>session came up. In 3GPP2 these sub sessions (termed auxiliary
>service instance) are initiated to support applications that
>need special treatments e.g. better than best effort QoS,
>header compression etc. Today, these sub sessions are not
>authorized using RADIUS messages (AR/AA). However, there are
>special accounting needs for these sub sessions i.e. separate
>accounting buckets are maintained for each of these sub
>sessions in the NAS.
>
>The intent of posting this message here is to initiate some
>discussion on sub sessions and possible RADIUS interaction.
>
>What would be the proper way to deal with these sub sessions?
>Do we need to define RADIUS procedures to handle auth and
>accounting of these sub sessions?
>Is there a possible link between the sub sessions and the need
>for sub types? Does the current (agreed) charter for RADEXT
>cover such a thing?
>
>-Kuntal
>

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

--------------34BBBC19491C8CC0AF601F36-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 May 2004 17:59:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: authorization of sub-sessions Date: Wed, 5 May 2004 13:58:47 -0400 Message-ID: Thread-Topic: authorization of sub-sessions Thread-Index: AcQyyj6B6CdVepldTGqLCeJS8Ij9BgAACqtw From: "Nelson, David" To: Posted on behalf of Kuntal Chowdhury: >Hi all, > >During a recent 3GPP2-IETF co-ordination call the issue of=20 >authorization of multiple auxiliary sub-sessions under a PPP=20 >session came up. In 3GPP2 these sub sessions (termed auxiliary=20 >service instance) are initiated to support applications that=20 >need special treatments e.g. better than best effort QoS,=20 >header compression etc. Today, these sub sessions are not=20 >authorized using RADIUS messages (AR/AA). However, there are=20 >special accounting needs for these sub sessions i.e. separate=20 >accounting buckets are maintained for each of these sub=20 >sessions in the NAS. > >The intent of posting this message here is to initiate some=20 >discussion on sub sessions and possible RADIUS interaction.=20 > >What would be the proper way to deal with these sub sessions?=20 >Do we need to define RADIUS procedures to handle auth and=20 >accounting of these sub sessions?=20 >Is there a possible link between the sub sessions and the need=20 >for sub types? Does the current (agreed) charter for RADEXT=20 >cover such a thing? > >-Kuntal > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 May 2004 06:12:46 +0000 From: Greg Weber Message-Id: <200405050610.CAA25522@cisco.com> Subject: RADIUS attribute design: some thoughts To: radiusext@ops.ietf.org Date: Wed, 5 May 2004 02:10:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In thinking about the RADIUS design guidelines work item from the current proposed charter, I thought it might provide some insight to look at some specific ways in which the VSA space is evolving. In part, it appears to be diverging from the data type encodings of the standard space due to simple lack of recommended route. Taking the SDOs as a microcosm of VSA usage, here are some usages I see in IS-835 (3GPP2), TS-129.061 (3GPP), and PacketCable 1.0 (CableLabs).[*] * Grouping data for .Compactness As with bit flags, multiply valued attributes (e.g. a list of IP addresses), and various overloaded strings which need parsing. .Logical relationship Attributes which describe multiple aspects of a single entity. RADIUS provides tags for this, but I haven't seen much usage of that mechanism in VSAs; sub attributes seem more popular and are probably more extensible. .Shared information As with a group of attributes which share a common timestamp, or a group of counters related to a common remote IP address. * Per-attribute encryption Perhaps a reaction to the overhead of IPsec or maybe to satisfy regulatory requirements for particular data items. * Fragmentation across VSAs For single VSA values exceeding the valid length of one attribute. These schemes seem to rely on the packet ordering/reordering restrictions on proxies- as does EAP. Diameter seems to accommodate most of these expressed needs- except perhaps compactness which may be an inappropriate goal for a protocol that uses self-described data (vs. GTP' or IPFIX). For RADIUS, I think the RADEXT attribute design guide should address at least these areas. Greg [*] http://www.3gpp2.com/Public_html/specs/X.S0011-005-C_v1.0_110703.pdf http://webapp.etsi.org/action%5CPU/20031007/ts_129061v050700p.pdf http://www.packetcable.com/downloads/specs/PKT-SP-EM-I09-040402.pdf -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 20:17:17 +0000 Message-ID: From: Avi Lior To: "'stefaan.de_cnodder@alcatel.be'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: redirection+prepaid Date: Tue, 4 May 2004 16:16:58 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Stefaan and all As you point out, rhe problem with extending the text field for this attribute is that we would break Diameter. I borrowed heavily from Diameter. Having said that in the next version of Redirection Draft, for different reasons, I had to change the syntax of that string. Here is the reason: If you want to remove a filter-rule or redirection-rule using COA push model then you have to send an attribute that you want to change. If you don't then the NAS will keep the attribute. By sending an attribute the NAS will replace all other attributes of the same type. BTW: The COA push model allows the RADIUS server to push attributes that it wants to change to the NAS. The other model is what I call the COA pull model which is a COA message that forces the NAS to reauthorize (send an Access-Request Service-Type Authorize-Only) and receives all the attributes in the Access-Accept message (hence "pull model"). The push model is not supported by Diameter. So two options: a) Keep the syntax the same. Therefore I would have to send a benign rule that will replace the other attributes; or b) Change the syntax slightly eg. If the attribute is set to "flush" then this flushes all the rules; I like option b). Note a couple of things: 1) Option b) could be extended so that we can selectively remove filter/redirection rules. 2) It does break the Diameter syntax but note that Diameter doesn't even support the COA push model for changing attributes so we would have to have some translation. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: May 4, 2004 3:50 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: redirection+prepaid > > > > Hi Avi, > > Ok, I see. In fact I was thinking about extending the text > field in for instance the NAS-Filter-Rule from "action dir > proto from src to dst [options]" to "action dir proto from > src to dst activation [options] " where activation can have > values "immediately", "quota_expired", ... this has the > problem that all possible cases has to be enumerated and that > it might not line up with diameter. Anyhow, the two options > below are also fine. > > regards, > Stefaan > > > Avi Lior wrote: > > > > Hi Stefaan and all, > > > > Your question is very timely and right on. We are > currently working > > on this in 3GPP2. > > > > Putting an attribute to indicate when something applies may > not work. > > It is possible that even under normal circumstances the session may > > have a filter applied. In the case where it's a prepaid session it > > could be that I have a filter/redirect attributes to be > applied when > > quota runs out and a filter id to be applied immediately. Since we > > cannot guarantee the order of different attributes this > will be hard > > to do with an additional attribute. If we could however group the > > redirection/filter attributes with the prepaid stuff then > this would > > do the trick. That is the essence of Option 2 below. > > > > I have identified two options (there could be others): > > > > Option 1: > > ========= > > > > When the quota reaches zero, in 3GPP2 the session is > terminated and an > > Access-Request Authorize-Only is sent back to report that > the session > > has terminated etc... > > > > My suggestion is to not terminate the session but rather, > wait for the > > reply to the Access-Request (above). That reply would be either: > > > > an Access-Reject (no quota drop the user) or; > > an Access-Accept with new quota (after all the user may have topped > > his > > account) or; > > an Access-Accept with redirection attributes. > > > > Problem with Option 1 is that during the time when we wait for the > > response to the Access-Request there could be revenue leakage. Any > > use could be applied to the new quota. So we would only > have revenue > > leakage if the user doesn't top up. Also it could be the case that > > the NAS will drop the session anyway after some (locally > configured) > > timeout period. > > > > Option 2: > > ========= > > > > For prepaid put the Redirection/Filter attributes in the PPAQ. > > Doesn't change the behavior of prepaid as specified by > 3GPP2. The NAS > > would apply any filter/redirection attributes it finds outside the > > PPAQ immediately. Those in the PPAQ would be acted on when > the quota > > runs out. > > > > This is what I have on the table in 3GPP2. > > > > Note the following: > > =================== > > > > a) 3GPP2 folks have not given me a clear indication of what is the > > best option. We are addressing this now so I will know > their opinions > > shortly. > > > > b) I preffer option 1 but not sure about how operators will > feel about > > revenue leakage of several seconds. Option 1 fixes the > problem of the > > subscriber toping off his account. Yes you have some potential for > > leakage but you may prevent a user from calling the call center to > > complain. Not for me to decide which is better. > > > > c) I have to check what Diameter-CC does about this. I would very > > much like to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid. > > > > Finally, I would very much like to hear what other folks > have to say > > about this. > > > > I really appreciate your comments. > > > > Avi > > > > > -----Original Message----- > > > From: stefaan.de_cnodder@alcatel.be > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > Sent: May 4, 2004 12:43 PM > > > To: radiusext@ops.ietf.org > > > Subject: redirection+prepaid > > > > > > > > > > > > Hi, > > > > > > I was wondering how the redirection in > > > draft-lior-radius-redirection-00 can be used for prepaid: the > > > filters/redirect is applied by the NAS as soon the attributes are > > > received by the NAS (either in access accept or CoA). How > can this > > > then be used for prepaid when the filters have to be applied when > > > there is no quota anymore? Would it not be better to add > something > > > to indicate when it has to be applied (e.g., immediately, when no > > > quota anymore, ...)? > > > > > > regards, > > > > > > Stefaan > > > > > > -- > > > to unsubscribe send a message to > radiusext-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: > > > > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 19:50:36 +0000 Message-ID: <4097F3FB.CCE3DE4A@alcatel.be> Date: Tue, 04 May 2004 21:50:19 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: Avi Lior CC: radiusext@ops.ietf.org Subject: Re: redirection+prepaid Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Avi, Ok, I see. In fact I was thinking about extending the text field in for instance the NAS-Filter-Rule from "action dir proto from src to dst [options]" to "action dir proto from src to dst activation [options] " where activation can have values "immediately", "quota_expired", ... this has the problem that all possible cases has to be enumerated and that it might not line up with diameter. Anyhow, the two options below are also fine. regards, Stefaan Avi Lior wrote: > > Hi Stefaan and all, > > Your question is very timely and right on. We are currently working on this > in 3GPP2. > > Putting an attribute to indicate when something applies may not work. It is > possible that even under normal circumstances the session may have a filter > applied. In the case where it's a prepaid session it could be that I have a > filter/redirect attributes to be applied when quota runs out and a filter id > to be applied immediately. Since we cannot guarantee the order of different > attributes this will be hard to do with an additional attribute. If we > could however group the redirection/filter attributes with the prepaid stuff > then this would do the trick. That is the essence of Option 2 below. > > I have identified two options (there could be others): > > Option 1: > ========= > > When the quota reaches zero, in 3GPP2 the session is terminated and an > Access-Request Authorize-Only is sent back to report that the session has > terminated etc... > > My suggestion is to not terminate the session but rather, wait for the reply > to the Access-Request (above). That reply would be either: > > an Access-Reject (no quota drop the user) or; > an Access-Accept with new quota (after all the user may have topped his > account) or; > an Access-Accept with redirection attributes. > > Problem with Option 1 is that during the time when we wait for the response > to the Access-Request there could be revenue leakage. Any use could be > applied to the new quota. So we would only have revenue leakage if the user > doesn't top up. Also it could be the case that the NAS will drop the > session anyway after some (locally configured) timeout period. > > Option 2: > ========= > > For prepaid put the Redirection/Filter attributes in the PPAQ. Doesn't > change the behavior of prepaid as specified by 3GPP2. > The NAS would apply any filter/redirection attributes it finds outside the > PPAQ immediately. Those in the PPAQ would be acted on when the quota runs > out. > > This is what I have on the table in 3GPP2. > > Note the following: > =================== > > a) 3GPP2 folks have not given me a clear indication of what is the best > option. We are addressing this now so I will know their opinions shortly. > > b) I preffer option 1 but not sure about how operators will feel about > revenue leakage of several seconds. Option 1 fixes the problem of the > subscriber toping off his account. Yes you have some potential for leakage > but you may prevent a user from calling the call center to complain. Not > for me to decide which is better. > > c) I have to check what Diameter-CC does about this. I would very much like > to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid. > > Finally, I would very much like to hear what other folks have to say about > this. > > I really appreciate your comments. > > Avi > > > -----Original Message----- > > From: stefaan.de_cnodder@alcatel.be > > [mailto:stefaan.de_cnodder@alcatel.be] > > Sent: May 4, 2004 12:43 PM > > To: radiusext@ops.ietf.org > > Subject: redirection+prepaid > > > > > > > > Hi, > > > > I was wondering how the redirection in > > draft-lior-radius-redirection-00 can be used for prepaid: the > > filters/redirect is applied by the NAS as soon the attributes > > are received by the NAS (either in access accept or CoA). How > > can this then be used for prepaid when the filters have to be > > applied when there is no quota anymore? Would it not be > > better to add something to indicate when it has to be applied > > (e.g., immediately, when no quota anymore, ...)? > > > > regards, > > > > Stefaan > > > > -- > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 19:47:41 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: redirection+prepaid Date: Tue, 4 May 2004 12:43:47 -0700 Message-ID: Thread-Topic: redirection+prepaid Thread-Index: AcQyCwO4A+vytxFxS2OF6uP6nPGo7wAA/lu0 From: "Blair T. Bullock" To: radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43210.1E0CA55D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C43210.1E0CA55D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 PiBJIHByZWZmZXIgb3B0aW9uIDEgYnV0IG5vdCBzdXJlIGFib3V0IGhvdyBvcGVyYXRvcnMgd2ls bCBmZWVsIGFib3V0DQo+cmV2ZW51ZSBsZWFrYWdlIG9mIHNldmVyYWwgc2Vjb25kcy4gIE9wdGlv biAxIGZpeGVzIHRoZSBwcm9ibGVtIG9mIHRoZQ0KPnN1YnNjcmliZXIgdG9waW5nIG9mZiBoaXMg YWNjb3VudC4gWWVzIHlvdSBoYXZlIHNvbWUgcG90ZW50aWFsIGZvciBsZWFrYWdlDQo+YnV0IHlv dSBtYXkgcHJldmVudCBhIHVzZXIgZnJvbSBjYWxsaW5nIHRoZSBjYWxsIGNlbnRlciB0byBjb21w bGFpbi4gIE5vdA0KPmZvciBtZSB0byBkZWNpZGUgd2hpY2ggaXMgYmV0dGVyLg0KPg0KIA0KSSB0 aGluayB5b3UgYXJlIHJpZ2h0IG9uIHRoZSBtb25leSBvbiBPcHRpb24gMSBzaW5jZSBtYW55IHNp bXBsZSBTZXNzaW9uLVRpbWVvdXQgbm9uLVZTQSBSQURJVVMgcHJlcGFpZCBzeXN0ZW1zIChlaXRo ZXIgVm9JUCBvciBkaWFsIElQKSBoYXZlIGluIHRoZSBwYXN0IG5vdCBhZGRyZXNzZWQgVG9wLW9m ZnM7IHNpbXBseSBraWxsaW5nIHRoZSBzZXNzaW9uIGF0IFNlc3Npb24tVGltZW91dC4gIElmIHRo ZSB1c2VyIGlzIGdvaW5nIHRvIGNhbGwtaW4gdG8gY29tcGxhaW4sICJJIGp1c3QgZmlsbGVkLXVw IHdpdGggdGhlIGNyZWRpdCBjYXJkIGFuZCB5b3Ugc3RpbGwga25vY2tlZCBtZSBvZmYiLCBtaW5v ciByZXZlbnVlIGxlYWthZ2Ugb2YgYSBmZXcgc2VjcyB0byBjaGVjayB0aGUgc3RhdHVzIG9mIHRo ZSB1c2VyJ3MgYmFsYW5jZSBhdCBkaXNjb25uZWN0IHRvIGF2b2lkIGEgc3VwcG9ydCBidXJkZW4g YW5kIHByb3ZpZGUgY29udGludWluZyAmIHNlYW1sZXNzIHByZXBhaWQgc2Vzc2lvbnMgaXMgbm90 IHJlYWxseSByZXZlbnVlIGxlYWthZ2UgYXQgYWxsLCBidXQgcmF0aGVyIGEgZGVzaXJlYWJsZSBh bmQgdmFsdWFibGUgcmVhdXRoIGZlYXR1cmUhDQoNCj5jKSBJIGhhdmUgdG8gY2hlY2sgd2hhdCBE aWFtZXRlci1DQyBkb2VzIGFib3V0IHRoaXMuICBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlDQo+dG8g aGF2ZSBEaWFtZXRlci1DQywgM0dQUDIgYW5kIFJBRElVUyBjb252ZXJnZSBvbiBwcmVwYWlkLiAN CiANCkhhbGxlbHVqYWghICBBIGNvbW1vbiBwcmVwYWlkIGZyYW1ld29yayB3b3VsZCBiZSBsb3Zl bHkuDQogDQotQmxhaXINCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEF2 aSBMaW9yIFttYWlsdG86YXZpQGJyaWRnZXdhdGVyc3lzdGVtcy5jb21dIA0KCVNlbnQ6IFR1ZSA1 LzQvMjAwNCAxMjowOCBQTSANCglUbzogJ3N0ZWZhYW4uZGVfY25vZGRlckBhbGNhdGVsLmJlJzsg cmFkaXVzZXh0QG9wcy5pZXRmLm9yZyANCglDYzogDQoJU3ViamVjdDogUkU6IHJlZGlyZWN0aW9u K3ByZXBhaWQNCgkNCgkNCg0KCUhpIFN0ZWZhYW4gYW5kIGFsbCwNCgkNCglZb3VyIHF1ZXN0aW9u IGlzIHZlcnkgdGltZWx5IGFuZCByaWdodCBvbi4gIFdlIGFyZSBjdXJyZW50bHkgd29ya2luZyBv biB0aGlzDQoJaW4gM0dQUDIuDQoJDQoJUHV0dGluZyBhbiBhdHRyaWJ1dGUgdG8gaW5kaWNhdGUg d2hlbiBzb21ldGhpbmcgYXBwbGllcyBtYXkgbm90IHdvcmsuICBJdCBpcw0KCXBvc3NpYmxlIHRo YXQgZXZlbiB1bmRlciBub3JtYWwgY2lyY3Vtc3RhbmNlcyB0aGUgc2Vzc2lvbiBtYXkgaGF2ZSBh IGZpbHRlcg0KCWFwcGxpZWQuICBJbiB0aGUgY2FzZSB3aGVyZSBpdCdzIGEgcHJlcGFpZCBzZXNz aW9uIGl0IGNvdWxkIGJlIHRoYXQgSSBoYXZlIGENCglmaWx0ZXIvcmVkaXJlY3QgYXR0cmlidXRl cyB0byBiZSBhcHBsaWVkIHdoZW4gcXVvdGEgcnVucyBvdXQgYW5kIGEgZmlsdGVyIGlkDQoJdG8g YmUgYXBwbGllZCBpbW1lZGlhdGVseS4gIFNpbmNlIHdlIGNhbm5vdCBndWFyYW50ZWUgdGhlIG9y ZGVyIG9mIGRpZmZlcmVudA0KCWF0dHJpYnV0ZXMgdGhpcyB3aWxsIGJlIGhhcmQgdG8gZG8gd2l0 aCBhbiBhZGRpdGlvbmFsIGF0dHJpYnV0ZS4gIElmIHdlDQoJY291bGQgaG93ZXZlciBncm91cCB0 aGUgcmVkaXJlY3Rpb24vZmlsdGVyIGF0dHJpYnV0ZXMgd2l0aCB0aGUgcHJlcGFpZCBzdHVmZg0K CXRoZW4gdGhpcyB3b3VsZCBkbyB0aGUgdHJpY2suICBUaGF0IGlzIHRoZSBlc3NlbmNlIG9mIE9w dGlvbiAyIGJlbG93Lg0KCQ0KCUkgaGF2ZSBpZGVudGlmaWVkIHR3byBvcHRpb25zICh0aGVyZSBj b3VsZCBiZSBvdGhlcnMpOg0KCQ0KCU9wdGlvbiAxOg0KCT09PT09PT09PQ0KCQ0KCVdoZW4gdGhl IHF1b3RhIHJlYWNoZXMgemVybywgaW4gM0dQUDIgdGhlIHNlc3Npb24gaXMgdGVybWluYXRlZCBh bmQgYW4NCglBY2Nlc3MtUmVxdWVzdCBBdXRob3JpemUtT25seSBpcyBzZW50IGJhY2sgdG8gcmVw b3J0IHRoYXQgdGhlIHNlc3Npb24gaGFzDQoJdGVybWluYXRlZCBldGMuLi4NCgkNCglNeSBzdWdn ZXN0aW9uIGlzIHRvIG5vdCB0ZXJtaW5hdGUgdGhlIHNlc3Npb24gYnV0IHJhdGhlciwgd2FpdCBm b3IgdGhlIHJlcGx5DQoJdG8gdGhlIEFjY2Vzcy1SZXF1ZXN0IChhYm92ZSkuICBUaGF0IHJlcGx5 IHdvdWxkIGJlIGVpdGhlcjoNCgkNCglhbiBBY2Nlc3MtUmVqZWN0IChubyBxdW90YSBkcm9wIHRo ZSB1c2VyKSBvcjsNCglhbiBBY2Nlc3MtQWNjZXB0IHdpdGggbmV3IHF1b3RhIChhZnRlciBhbGwg dGhlIHVzZXIgbWF5IGhhdmUgdG9wcGVkIGhpcw0KCWFjY291bnQpIG9yOw0KCWFuIEFjY2Vzcy1B Y2NlcHQgd2l0aCByZWRpcmVjdGlvbiBhdHRyaWJ1dGVzLg0KCQ0KCVByb2JsZW0gd2l0aCBPcHRp b24gMSBpcyB0aGF0IGR1cmluZyB0aGUgdGltZSB3aGVuIHdlIHdhaXQgZm9yIHRoZSByZXNwb25z ZQ0KCXRvIHRoZSBBY2Nlc3MtUmVxdWVzdCB0aGVyZSBjb3VsZCBiZSByZXZlbnVlIGxlYWthZ2Uu ICBBbnkgdXNlIGNvdWxkIGJlDQoJYXBwbGllZCB0byB0aGUgbmV3IHF1b3RhLiAgU28gd2Ugd291 bGQgb25seSBoYXZlIHJldmVudWUgbGVha2FnZSBpZiB0aGUgdXNlcg0KCWRvZXNuJ3QgdG9wIHVw LiAgQWxzbyBpdCBjb3VsZCBiZSB0aGUgY2FzZSB0aGF0IHRoZSBOQVMgd2lsbCBkcm9wIHRoZQ0K CXNlc3Npb24gYW55d2F5IGFmdGVyIHNvbWUgKGxvY2FsbHkgY29uZmlndXJlZCkgdGltZW91dCBw ZXJpb2QuDQoJDQoJT3B0aW9uIDI6DQoJPT09PT09PT09DQoJDQoJRm9yIHByZXBhaWQgcHV0IHRo ZSBSZWRpcmVjdGlvbi9GaWx0ZXIgYXR0cmlidXRlcyBpbiB0aGUgUFBBUS4gIERvZXNuJ3QNCglj aGFuZ2UgdGhlIGJlaGF2aW9yIG9mIHByZXBhaWQgYXMgc3BlY2lmaWVkIGJ5IDNHUFAyLg0KCVRo ZSBOQVMgd291bGQgYXBwbHkgYW55IGZpbHRlci9yZWRpcmVjdGlvbiBhdHRyaWJ1dGVzIGl0IGZp bmRzIG91dHNpZGUgdGhlDQoJUFBBUSBpbW1lZGlhdGVseS4gIFRob3NlIGluIHRoZSBQUEFRIHdv dWxkIGJlIGFjdGVkIG9uIHdoZW4gdGhlIHF1b3RhIHJ1bnMNCglvdXQuDQoJDQoJVGhpcyBpcyB3 aGF0IEkgaGF2ZSBvbiB0aGUgdGFibGUgaW4gM0dQUDIuDQoJDQoJTm90ZSB0aGUgZm9sbG93aW5n Og0KCT09PT09PT09PT09PT09PT09PT0NCgkNCglhKSAzR1BQMiBmb2xrcyBoYXZlIG5vdCBnaXZl biBtZSBhIGNsZWFyIGluZGljYXRpb24gb2Ygd2hhdCBpcyB0aGUgYmVzdA0KCW9wdGlvbi4gIFdl IGFyZSBhZGRyZXNzaW5nIHRoaXMgbm93IHNvIEkgd2lsbCBrbm93IHRoZWlyIG9waW5pb25zIHNo b3J0bHkuDQoJDQoJYikgSSBwcmVmZmVyIG9wdGlvbiAxIGJ1dCBub3Qgc3VyZSBhYm91dCBob3cg b3BlcmF0b3JzIHdpbGwgZmVlbCBhYm91dA0KCXJldmVudWUgbGVha2FnZSBvZiBzZXZlcmFsIHNl Y29uZHMuICBPcHRpb24gMSBmaXhlcyB0aGUgcHJvYmxlbSBvZiB0aGUNCglzdWJzY3JpYmVyIHRv cGluZyBvZmYgaGlzIGFjY291bnQuIFllcyB5b3UgaGF2ZSBzb21lIHBvdGVudGlhbCBmb3IgbGVh a2FnZQ0KCWJ1dCB5b3UgbWF5IHByZXZlbnQgYSB1c2VyIGZyb20gY2FsbGluZyB0aGUgY2FsbCBj ZW50ZXIgdG8gY29tcGxhaW4uICBOb3QNCglmb3IgbWUgdG8gZGVjaWRlIHdoaWNoIGlzIGJldHRl ci4NCgkNCgljKSBJIGhhdmUgdG8gY2hlY2sgd2hhdCBEaWFtZXRlci1DQyBkb2VzIGFib3V0IHRo aXMuICBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlDQoJdG8gaGF2ZSBEaWFtZXRlci1DQywgM0dQUDIg YW5kIFJBRElVUyBjb252ZXJnZSBvbiBwcmVwYWlkLiANCgkNCglGaW5hbGx5LCBJIHdvdWxkIHZl cnkgbXVjaCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlciBmb2xrcyBoYXZlIHRvIHNheSBhYm91dA0K CXRoaXMuDQoJDQoJSSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLg0KCQ0KCUF2aQ0K CQ0KCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206IHN0ZWZhYW4uZGVfY25v ZGRlckBhbGNhdGVsLmJlDQoJPiBbbWFpbHRvOnN0ZWZhYW4uZGVfY25vZGRlckBhbGNhdGVsLmJl XQ0KCT4gU2VudDogTWF5IDQsIDIwMDQgMTI6NDMgUE0NCgk+IFRvOiByYWRpdXNleHRAb3BzLmll dGYub3JnDQoJPiBTdWJqZWN0OiByZWRpcmVjdGlvbitwcmVwYWlkDQoJPg0KCT4NCgk+DQoJPiBI aSwNCgk+DQoJPiBJIHdhcyB3b25kZXJpbmcgaG93IHRoZSByZWRpcmVjdGlvbiBpbg0KCT4gZHJh ZnQtbGlvci1yYWRpdXMtcmVkaXJlY3Rpb24tMDAgY2FuIGJlIHVzZWQgZm9yIHByZXBhaWQ6IHRo ZQ0KCT4gZmlsdGVycy9yZWRpcmVjdCBpcyBhcHBsaWVkIGJ5IHRoZSBOQVMgYXMgc29vbiB0aGUg YXR0cmlidXRlcw0KCT4gYXJlIHJlY2VpdmVkIGJ5IHRoZSBOQVMgKGVpdGhlciBpbiBhY2Nlc3Mg YWNjZXB0IG9yIENvQSkuIEhvdw0KCT4gY2FuIHRoaXMgdGhlbiBiZSB1c2VkIGZvciBwcmVwYWlk IHdoZW4gdGhlIGZpbHRlcnMgaGF2ZSB0byBiZQ0KCT4gYXBwbGllZCB3aGVuIHRoZXJlIGlzIG5v IHF1b3RhIGFueW1vcmU/IFdvdWxkIGl0IG5vdCBiZQ0KCT4gYmV0dGVyIHRvIGFkZCBzb21ldGhp bmcgdG8gaW5kaWNhdGUgd2hlbiBpdCBoYXMgdG8gYmUgYXBwbGllZA0KCT4gKGUuZy4sIGltbWVk aWF0ZWx5LCB3aGVuIG5vIHF1b3RhIGFueW1vcmUsIC4uLik/DQoJPg0KCT4gcmVnYXJkcywNCgk+ DQoJPiBTdGVmYWFuDQoJPg0KCT4gLS0NCgk+IHRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdl IHRvDQoJPiByYWRpdXNleHQtcmVxdWVzdEBvcHMuaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCAndW5z dWJzY3JpYmUnIGluDQoJPiBhIHNpbmdsZSBsaW5lIGFzIHRoZSBtZXNzYWdlIHRleHQgYm9keS4N Cgk+IGFyY2hpdmU6IDxodHRwOi8vcHNnLmNvbS9saXN0cy9yYWRpdXNleHQvPg0KCT4NCgkNCgkt LQ0KCXRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIHJhZGl1c2V4dC1yZXF1ZXN0QG9w cy5pZXRmLm9yZyB3aXRoDQoJdGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNpbmdsZSBsaW5l IGFzIHRoZSBtZXNzYWdlIHRleHQgYm9keS4NCglhcmNoaXZlOiA8aHR0cDovL3BzZy5jb20vbGlz dHMvcmFkaXVzZXh0Lz4NCgkNCgkNCg0K ------_=_NextPart_001_01C43210.1E0CA55D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SRTogcmVkaXJlY3Rpb24r cHJlcGFpZDwvVElUTEU+CjwvSEVBRD4KPEJPRFkgZGlyPWx0cj4KPERJVj48Rk9OVCBzaXplPTI+ Jmd0OyZuYnNwO0kgcHJlZmZlciBvcHRpb24gMSBidXQgbm90IHN1cmUgYWJvdXQgaG93IG9wZXJh dG9ycyAKd2lsbCBmZWVsIGFib3V0PEJSPiZndDtyZXZlbnVlIGxlYWthZ2Ugb2Ygc2V2ZXJhbCBz ZWNvbmRzLiZuYnNwOyBPcHRpb24gMSBmaXhlcyAKdGhlIHByb2JsZW0gb2YgdGhlPEJSPiZndDtz dWJzY3JpYmVyIHRvcGluZyBvZmYgaGlzIGFjY291bnQuIFllcyB5b3UgaGF2ZSBzb21lIApwb3Rl bnRpYWwgZm9yIGxlYWthZ2U8QlI+Jmd0O2J1dCB5b3UgbWF5IHByZXZlbnQgYSB1c2VyIGZyb20g Y2FsbGluZyB0aGUgY2FsbCAKY2VudGVyIHRvIGNvbXBsYWluLiZuYnNwOyBOb3Q8QlI+Jmd0O2Zv ciBtZSB0byBkZWNpZGUgd2hpY2ggaXMgCmJldHRlci48QlI+Jmd0OzwvRk9OVD48Rk9OVCBzaXpl PTI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SSB0aGluayB5b3UgYXJlIHJpZ2h0IG9u IHRoZSBtb25leSBvbiBPcHRpb24gMSBzaW5jZSBtYW55IHNpbXBsZSAKU2Vzc2lvbi1UaW1lb3V0 IG5vbi1WU0EgUkFESVVTIHByZXBhaWQgc3lzdGVtcyAoZWl0aGVyIFZvSVAgb3IgZGlhbCBJUCkg aGF2ZSBpbiAKdGhlIHBhc3Qgbm90IGFkZHJlc3NlZCBUb3Atb2Zmczsgc2ltcGx5IGtpbGxpbmcg dGhlIHNlc3Npb24gYXQgClNlc3Npb24tVGltZW91dC4mbmJzcDsgSWYgdGhlIHVzZXIgaXMgZ29p bmcgdG8gY2FsbC1pbiB0byBjb21wbGFpbiwgIkkganVzdCAKZmlsbGVkLXVwIHdpdGggdGhlIGNy ZWRpdCBjYXJkIGFuZCB5b3Ugc3RpbGwga25vY2tlZCBtZSBvZmYiLCBtaW5vciByZXZlbnVlIAps ZWFrYWdlJm5ic3A7b2YgYSBmZXcgc2VjcyZuYnNwO3RvIGNoZWNrIHRoZSBzdGF0dXMgb2YgdGhl IHVzZXIncyAKYmFsYW5jZSZuYnNwO2F0IGRpc2Nvbm5lY3QgdG8gYXZvaWQgYSBzdXBwb3J0IGJ1 cmRlbiBhbmQgcHJvdmlkZSBjb250aW51aW5nIAomYW1wOyBzZWFtbGVzcyBwcmVwYWlkIHNlc3Np b25zJm5ic3A7aXMgbm90IHJlYWxseSByZXZlbnVlIGxlYWthZ2UgYXQgYWxsLCBidXQgCnJhdGhl ciBhIGRlc2lyZWFibGUgYW5kIHZhbHVhYmxlJm5ic3A7cmVhdXRoIGZlYXR1cmUhPC9ESVY+CjxE SVY+PEJSPiZndDtjKSBJIGhhdmUgdG8gY2hlY2sgd2hhdCBEaWFtZXRlci1DQyBkb2VzIGFib3V0 IHRoaXMuJm5ic3A7IEkgd291bGQgCnZlcnkgbXVjaCBsaWtlPEJSPiZndDt0byBoYXZlIERpYW1l dGVyLUNDLCAzR1BQMiBhbmQgUkFESVVTIGNvbnZlcmdlIG9uIApwcmVwYWlkLiZuYnNwOzwvRk9O VD48L0RJVj4KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgo8RElWPjxGT05U IHNpemU9Mj5IYWxsZWx1amFoISZuYnNwOyBBIGNvbW1vbiBwcmVwYWlkIGZyYW1ld29yayB3b3Vs ZCBiZSAKbG92ZWx5LjwvRk9OVD48L0RJVj4KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPgo8RElWPjxGT05UIHNpemU9Mj4tQmxhaXI8L0ZPTlQ+PC9ESVY+CjxCTE9DS1FVT1RF IGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4KICA8RElWPjxGT05UIHNpemU9Mj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8L0I+IEF2aSBMaW9yIAogIFtt YWlsdG86YXZpQGJyaWRnZXdhdGVyc3lzdGVtcy5jb21dIDxCUj48Qj5TZW50OjwvQj4gVHVlIDUv NC8yMDA0IDEyOjA4IFBNIAogIDxCUj48Qj5Ubzo8L0I+ICdzdGVmYWFuLmRlX2Nub2RkZXJAYWxj YXRlbC5iZSc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcgCiAgPEJSPjxCPkNjOjwvQj4gPEJSPjxC PlN1YmplY3Q6PC9CPiBSRTogCnJlZGlyZWN0aW9uK3ByZXBhaWQ8QlI+PEJSPjwvRk9OVD48L0RJ Vj4KICA8UD48Rk9OVCBzaXplPTI+SGkgU3RlZmFhbiBhbmQgYWxsLDxCUj48QlI+WW91ciBxdWVz dGlvbiBpcyB2ZXJ5IHRpbWVseSBhbmQgCiAgcmlnaHQgb24uJm5ic3A7IFdlIGFyZSBjdXJyZW50 bHkgd29ya2luZyBvbiB0aGlzPEJSPmluIDNHUFAyLjxCUj48QlI+UHV0dGluZyAKICBhbiBhdHRy aWJ1dGUgdG8gaW5kaWNhdGUgd2hlbiBzb21ldGhpbmcgYXBwbGllcyBtYXkgbm90IHdvcmsuJm5i c3A7IEl0IAogIGlzPEJSPnBvc3NpYmxlIHRoYXQgZXZlbiB1bmRlciBub3JtYWwgY2lyY3Vtc3Rh bmNlcyB0aGUgc2Vzc2lvbiBtYXkgaGF2ZSBhIAogIGZpbHRlcjxCUj5hcHBsaWVkLiZuYnNwOyBJ biB0aGUgY2FzZSB3aGVyZSBpdCdzIGEgcHJlcGFpZCBzZXNzaW9uIGl0IGNvdWxkIGJlIAogIHRo YXQgSSBoYXZlIGE8QlI+ZmlsdGVyL3JlZGlyZWN0IGF0dHJpYnV0ZXMgdG8gYmUgYXBwbGllZCB3 aGVuIHF1b3RhIHJ1bnMgb3V0IAogIGFuZCBhIGZpbHRlciBpZDxCUj50byBiZSBhcHBsaWVkIGlt bWVkaWF0ZWx5LiZuYnNwOyBTaW5jZSB3ZSBjYW5ub3QgZ3VhcmFudGVlIAogIHRoZSBvcmRlciBv ZiBkaWZmZXJlbnQ8QlI+YXR0cmlidXRlcyB0aGlzIHdpbGwgYmUgaGFyZCB0byBkbyB3aXRoIGFu IAogIGFkZGl0aW9uYWwgYXR0cmlidXRlLiZuYnNwOyBJZiB3ZTxCUj5jb3VsZCBob3dldmVyIGdy b3VwIHRoZSAKICByZWRpcmVjdGlvbi9maWx0ZXIgYXR0cmlidXRlcyB3aXRoIHRoZSBwcmVwYWlk IHN0dWZmPEJSPnRoZW4gdGhpcyB3b3VsZCBkbyB0aGUgCiAgdHJpY2suJm5ic3A7IFRoYXQgaXMg dGhlIGVzc2VuY2Ugb2YgT3B0aW9uIDIgYmVsb3cuPEJSPjxCUj5JIGhhdmUgaWRlbnRpZmllZCAK ICB0d28gb3B0aW9ucyAodGhlcmUgY291bGQgYmUgb3RoZXJzKTo8QlI+PEJSPk9wdGlvbiAxOjxC Uj49PT09PT09PT08QlI+PEJSPldoZW4gCiAgdGhlIHF1b3RhIHJlYWNoZXMgemVybywgaW4gM0dQ UDIgdGhlIHNlc3Npb24gaXMgdGVybWluYXRlZCBhbmQgCiAgYW48QlI+QWNjZXNzLVJlcXVlc3Qg QXV0aG9yaXplLU9ubHkgaXMgc2VudCBiYWNrIHRvIHJlcG9ydCB0aGF0IHRoZSBzZXNzaW9uIAog IGhhczxCUj50ZXJtaW5hdGVkIGV0Yy4uLjxCUj48QlI+TXkgc3VnZ2VzdGlvbiBpcyB0byBub3Qg dGVybWluYXRlIHRoZSBzZXNzaW9uIAogIGJ1dCByYXRoZXIsIHdhaXQgZm9yIHRoZSByZXBseTxC Uj50byB0aGUgQWNjZXNzLVJlcXVlc3QgKGFib3ZlKS4mbmJzcDsgVGhhdCAKICByZXBseSB3b3Vs ZCBiZSBlaXRoZXI6PEJSPjxCUj5hbiBBY2Nlc3MtUmVqZWN0IChubyBxdW90YSBkcm9wIHRoZSB1 c2VyKSAKICBvcjs8QlI+YW4gQWNjZXNzLUFjY2VwdCB3aXRoIG5ldyBxdW90YSAoYWZ0ZXIgYWxs IHRoZSB1c2VyIG1heSBoYXZlIHRvcHBlZCAKICBoaXM8QlI+YWNjb3VudCkgb3I7PEJSPmFuIEFj Y2Vzcy1BY2NlcHQgd2l0aCByZWRpcmVjdGlvbiAKICBhdHRyaWJ1dGVzLjxCUj48QlI+UHJvYmxl bSB3aXRoIE9wdGlvbiAxIGlzIHRoYXQgZHVyaW5nIHRoZSB0aW1lIHdoZW4gd2Ugd2FpdCAKICBm b3IgdGhlIHJlc3BvbnNlPEJSPnRvIHRoZSBBY2Nlc3MtUmVxdWVzdCB0aGVyZSBjb3VsZCBiZSBy ZXZlbnVlIAogIGxlYWthZ2UuJm5ic3A7IEFueSB1c2UgY291bGQgYmU8QlI+YXBwbGllZCB0byB0 aGUgbmV3IHF1b3RhLiZuYnNwOyBTbyB3ZSB3b3VsZCAKICBvbmx5IGhhdmUgcmV2ZW51ZSBsZWFr YWdlIGlmIHRoZSB1c2VyPEJSPmRvZXNuJ3QgdG9wIHVwLiZuYnNwOyBBbHNvIGl0IGNvdWxkIAog IGJlIHRoZSBjYXNlIHRoYXQgdGhlIE5BUyB3aWxsIGRyb3AgdGhlPEJSPnNlc3Npb24gYW55d2F5 IGFmdGVyIHNvbWUgKGxvY2FsbHkgCiAgY29uZmlndXJlZCkgdGltZW91dCBwZXJpb2QuPEJSPjxC Uj5PcHRpb24gMjo8QlI+PT09PT09PT09PEJSPjxCUj5Gb3IgcHJlcGFpZCAKICBwdXQgdGhlIFJl ZGlyZWN0aW9uL0ZpbHRlciBhdHRyaWJ1dGVzIGluIHRoZSBQUEFRLiZuYnNwOyBEb2Vzbid0PEJS PmNoYW5nZSB0aGUgCiAgYmVoYXZpb3Igb2YgcHJlcGFpZCBhcyBzcGVjaWZpZWQgYnkgM0dQUDIu PEJSPlRoZSBOQVMgd291bGQgYXBwbHkgYW55IAogIGZpbHRlci9yZWRpcmVjdGlvbiBhdHRyaWJ1 dGVzIGl0IGZpbmRzIG91dHNpZGUgdGhlPEJSPlBQQVEgaW1tZWRpYXRlbHkuJm5ic3A7IAogIFRo b3NlIGluIHRoZSBQUEFRIHdvdWxkIGJlIGFjdGVkIG9uIHdoZW4gdGhlIHF1b3RhIHJ1bnM8QlI+ b3V0LjxCUj48QlI+VGhpcyBpcyAKICB3aGF0IEkgaGF2ZSBvbiB0aGUgdGFibGUgaW4gM0dQUDIu PEJSPjxCUj5Ob3RlIHRoZSAKICBmb2xsb3dpbmc6PEJSPj09PT09PT09PT09PT09PT09PT08QlI+ PEJSPmEpIDNHUFAyIGZvbGtzIGhhdmUgbm90IGdpdmVuIG1lIGEgCiAgY2xlYXIgaW5kaWNhdGlv biBvZiB3aGF0IGlzIHRoZSBiZXN0PEJSPm9wdGlvbi4mbmJzcDsgV2UgYXJlIGFkZHJlc3Npbmcg dGhpcyAKICBub3cgc28gSSB3aWxsIGtub3cgdGhlaXIgb3BpbmlvbnMgc2hvcnRseS48QlI+PEJS PmIpIEkgcHJlZmZlciBvcHRpb24gMSBidXQgCiAgbm90IHN1cmUgYWJvdXQgaG93IG9wZXJhdG9y cyB3aWxsIGZlZWwgYWJvdXQ8QlI+cmV2ZW51ZSBsZWFrYWdlIG9mIHNldmVyYWwgCiAgc2Vjb25k cy4mbmJzcDsgT3B0aW9uIDEgZml4ZXMgdGhlIHByb2JsZW0gb2YgdGhlPEJSPnN1YnNjcmliZXIg dG9waW5nIG9mZiBoaXMgCiAgYWNjb3VudC4gWWVzIHlvdSBoYXZlIHNvbWUgcG90ZW50aWFsIGZv ciBsZWFrYWdlPEJSPmJ1dCB5b3UgbWF5IHByZXZlbnQgYSB1c2VyIAogIGZyb20gY2FsbGluZyB0 aGUgY2FsbCBjZW50ZXIgdG8gY29tcGxhaW4uJm5ic3A7IE5vdDxCUj5mb3IgbWUgdG8gZGVjaWRl IHdoaWNoIAogIGlzIGJldHRlci48QlI+PEJSPmMpIEkgaGF2ZSB0byBjaGVjayB3aGF0IERpYW1l dGVyLUNDIGRvZXMgYWJvdXQgdGhpcy4mbmJzcDsgSSAKICB3b3VsZCB2ZXJ5IG11Y2ggbGlrZTxC Uj50byBoYXZlIERpYW1ldGVyLUNDLCAzR1BQMiBhbmQgUkFESVVTIGNvbnZlcmdlIG9uIAogIHBy ZXBhaWQuJm5ic3A7PEJSPjxCUj5GaW5hbGx5LCBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIGhl YXIgd2hhdCBvdGhlciBmb2xrcyAKICBoYXZlIHRvIHNheSBhYm91dDxCUj50aGlzLjxCUj48QlI+ SSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIAogIGNvbW1lbnRzLjxCUj48QlI+QXZpPEJSPjxCUj4m Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgRnJvbTogCiAgc3RlZmFhbi5k ZV9jbm9kZGVyQGFsY2F0ZWwuYmU8QlI+Jmd0OyBbPEEgCiAgaHJlZj0ibWFpbHRvOnN0ZWZhYW4u ZGVfY25vZGRlckBhbGNhdGVsLmJlIj5tYWlsdG86c3RlZmFhbi5kZV9jbm9kZGVyQGFsY2F0ZWwu YmU8L0E+XTxCUj4mZ3Q7IAogIFNlbnQ6IE1heSA0LCAyMDA0IDEyOjQzIFBNPEJSPiZndDsgVG86 IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc8QlI+Jmd0OyBTdWJqZWN0OiAKICByZWRpcmVjdGlvbitw cmVwYWlkPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSGksPEJSPiZndDs8QlI+Jmd0 OyBJIHdhcyAKICB3b25kZXJpbmcgaG93IHRoZSByZWRpcmVjdGlvbiBpbjxCUj4mZ3Q7IGRyYWZ0 LWxpb3ItcmFkaXVzLXJlZGlyZWN0aW9uLTAwIGNhbiAKICBiZSB1c2VkIGZvciBwcmVwYWlkOiB0 aGU8QlI+Jmd0OyBmaWx0ZXJzL3JlZGlyZWN0IGlzIGFwcGxpZWQgYnkgdGhlIE5BUyBhcyAKICBz b29uIHRoZSBhdHRyaWJ1dGVzPEJSPiZndDsgYXJlIHJlY2VpdmVkIGJ5IHRoZSBOQVMgKGVpdGhl ciBpbiBhY2Nlc3MgYWNjZXB0IAogIG9yIENvQSkuIEhvdzxCUj4mZ3Q7IGNhbiB0aGlzIHRoZW4g YmUgdXNlZCBmb3IgcHJlcGFpZCB3aGVuIHRoZSBmaWx0ZXJzIGhhdmUgCiAgdG8gYmU8QlI+Jmd0 OyBhcHBsaWVkIHdoZW4gdGhlcmUgaXMgbm8gcXVvdGEgYW55bW9yZT8gV291bGQgaXQgbm90IGJl PEJSPiZndDsgCiAgYmV0dGVyIHRvIGFkZCBzb21ldGhpbmcgdG8gaW5kaWNhdGUgd2hlbiBpdCBo YXMgdG8gYmUgYXBwbGllZDxCUj4mZ3Q7IChlLmcuLCAKICBpbW1lZGlhdGVseSwgd2hlbiBubyBx dW90YSBhbnltb3JlLCAuLi4pPzxCUj4mZ3Q7PEJSPiZndDsgCiAgcmVnYXJkcyw8QlI+Jmd0OzxC Uj4mZ3Q7IFN0ZWZhYW48QlI+Jmd0OzxCUj4mZ3Q7IC0tPEJSPiZndDsgdG8gdW5zdWJzY3JpYmUg CiAgc2VuZCBhIG1lc3NhZ2UgdG88QlI+Jmd0OyByYWRpdXNleHQtcmVxdWVzdEBvcHMuaWV0Zi5v cmcgd2l0aCB0aGUgd29yZCAKICAndW5zdWJzY3JpYmUnIGluPEJSPiZndDsgYSBzaW5nbGUgbGlu ZSBhcyB0aGUgbWVzc2FnZSB0ZXh0IGJvZHkuPEJSPiZndDsgCiAgYXJjaGl2ZTogJmx0OzxBIAog IGhyZWY9Imh0dHA6Ly9wc2cuY29tL2xpc3RzL3JhZGl1c2V4dC8iPmh0dHA6Ly9wc2cuY29tL2xp c3RzL3JhZGl1c2V4dC88L0E+Jmd0OzxCUj4mZ3Q7PEJSPjxCUj4tLTxCUj50byAKICB1bnN1YnNj cmliZSBzZW5kIGEgbWVzc2FnZSB0byByYWRpdXNleHQtcmVxdWVzdEBvcHMuaWV0Zi5vcmcgd2l0 aDxCUj50aGUgd29yZCAKICAndW5zdWJzY3JpYmUnIGluIGEgc2luZ2xlIGxpbmUgYXMgdGhlIG1l c3NhZ2UgdGV4dCBib2R5LjxCUj5hcmNoaXZlOiAmbHQ7PEEgCiAgaHJlZj0iaHR0cDovL3BzZy5j b20vbGlzdHMvcmFkaXVzZXh0LyI+aHR0cDovL3BzZy5jb20vbGlzdHMvcmFkaXVzZXh0LzwvQT4m Z3Q7PEJSPjxCUj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KCjwvQk9EWT4KPC9IVE1MPg== ------_=_NextPart_001_01C43210.1E0CA55D-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 19:41:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 22:40:54 +0300 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQx4IUJaHJG6Z0DTx6TTq+9nkUV3wALwsKA From: To: , Cc: Jari, > This would make it be late from, say, 3GPP release 6 specifications > which probably would like to refer to an IETF spec on this. > Can you remind me why there is a dependency on the guidelines > and WLAN attributes? I had been assuming that the guidelines > are needed if you do something complicated, like subattributes > or SDO-specific attributes. But I'm not sure we need them > for the WLAN attrs draft. Or I would hope we can get by without > them -- maybe I'm mistaken. Well, as I understand, 3GPP is looking at having things wrapped-up for Rel. 6 by September, so I doubt there is anyway to get anything ready for that. Perhaps it would be best to handle any 3GPP dependencies via the 3GPP liason. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 19:08:55 +0000 Message-ID: From: Avi Lior To: "'stefaan.de_cnodder@alcatel.be'" , radiusext@ops.ietf.org Subject: RE: redirection+prepaid Date: Tue, 4 May 2004 15:08:35 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Stefaan and all, Your question is very timely and right on. We are currently working on this in 3GPP2. Putting an attribute to indicate when something applies may not work. It is possible that even under normal circumstances the session may have a filter applied. In the case where it's a prepaid session it could be that I have a filter/redirect attributes to be applied when quota runs out and a filter id to be applied immediately. Since we cannot guarantee the order of different attributes this will be hard to do with an additional attribute. If we could however group the redirection/filter attributes with the prepaid stuff then this would do the trick. That is the essence of Option 2 below. I have identified two options (there could be others): Option 1: ========= When the quota reaches zero, in 3GPP2 the session is terminated and an Access-Request Authorize-Only is sent back to report that the session has terminated etc... My suggestion is to not terminate the session but rather, wait for the reply to the Access-Request (above). That reply would be either: an Access-Reject (no quota drop the user) or; an Access-Accept with new quota (after all the user may have topped his account) or; an Access-Accept with redirection attributes. Problem with Option 1 is that during the time when we wait for the response to the Access-Request there could be revenue leakage. Any use could be applied to the new quota. So we would only have revenue leakage if the user doesn't top up. Also it could be the case that the NAS will drop the session anyway after some (locally configured) timeout period. Option 2: ========= For prepaid put the Redirection/Filter attributes in the PPAQ. Doesn't change the behavior of prepaid as specified by 3GPP2. The NAS would apply any filter/redirection attributes it finds outside the PPAQ immediately. Those in the PPAQ would be acted on when the quota runs out. This is what I have on the table in 3GPP2. Note the following: =================== a) 3GPP2 folks have not given me a clear indication of what is the best option. We are addressing this now so I will know their opinions shortly. b) I preffer option 1 but not sure about how operators will feel about revenue leakage of several seconds. Option 1 fixes the problem of the subscriber toping off his account. Yes you have some potential for leakage but you may prevent a user from calling the call center to complain. Not for me to decide which is better. c) I have to check what Diameter-CC does about this. I would very much like to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid. Finally, I would very much like to hear what other folks have to say about this. I really appreciate your comments. Avi > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: May 4, 2004 12:43 PM > To: radiusext@ops.ietf.org > Subject: redirection+prepaid > > > > Hi, > > I was wondering how the redirection in > draft-lior-radius-redirection-00 can be used for prepaid: the > filters/redirect is applied by the NAS as soon the attributes > are received by the NAS (either in access accept or CoA). How > can this then be used for prepaid when the filters have to be > applied when there is no quota anymore? Would it not be > better to add something to indicate when it has to be applied > (e.g., immediately, when no quota anymore, ...)? > > regards, > > Stefaan > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 18:08:51 +0000 Message-ID: <4097DB6A.1090502@piuha.net> Date: Tue, 04 May 2004 21:05:30 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS drafts review -- LAN attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > We did have an extended debate over subtypes. We need to see if > consensus has emerged, or if we've all simply grown weary of the debate. ;-) My suggestion is to avoid this debate for the {,W}LAN attributes work. Lets keep it simple. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 18:06:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 14:06:24 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQx4Eo4cfN8hZkxRbGXv4I9ulETywAA7dLwAAGE3WAABYGUIA== From: "Nelson, David" To: > [FA] I don't think we need design guidelines for LAN attributes > (including WLAN) -- because as Jari said this is not a complicated task. Perhaps not. There's certainly no issue with starting these work items in parallel. It should soon become obvious if there *is* a need to apply the design guidelines. Of course, *if* there is a need identified, then finishing the design guidelines first would be the proper procedure, much like completing the requirements document before you design the protocol. > Could you be more specific what you have in mind for design guidelines? > We spent over 6 month arguing about subtypes -- and if we spend another > 6 month arguing the design guidelines, for sure we will never get this > done! We did have an extended debate over subtypes. We need to see if consensus has emerged, or if we've all simply grown weary of the debate. Once the consensus is determined we need to write it down in the design guidelines, or run the risk of having the same 6-month debate at some future time. :-( Creating the design guidelines is an important work item, and per our milestones, it is one of the first deliverables. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 17:21:40 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 10:19:33 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAIi4TEAAG3H6w From: "Adrangi, Farid" To: "Romascanu, Dan (Dan)" , Cc: "Nelson, David" Hi Dan, Thanks. In that case, Please allow me to post an update version in a day or two for our discussion. BR, FArid > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Tuesday, May 04, 2004 7:03 AM > To: Adrangi, Farid; radiusext@ops.ietf.org > Cc: Nelson, David > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 > Farid, >=20 > draft-adrangi-radius-extension-for-pwlan-00.txt is expired=20 > and not available any longer in the IETF repository. I guess=20 > that you intent to re-submit it, as you are requiring=20 > comments. Do you have an alternative URL to access it meantime? >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid > > Sent: 04 May, 2004 1:04 AM > > To: radiusext@ops.ietf.org > > Cc: Nelson, David > > Subject: RE: RADIUS drafts review -- LAN attributes > >=20 > >=20 > > Hi David, all > >=20 > > There are a number of drafts on LAN attributes: > >=20 > > 1) http://www.ietf.org/internet-drafts/draft-lior-radius-redirect > > ion-00.txt > >=20 > > 2) http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandw > > idth-capab > > ility-00.txt > >=20 > > 3) There were two original drafts on LAN attributes: black=20 > and adrangi > > drafts:=20 > http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten > sion-for-p > wlan-00.txt >=20 > Note : Couldn't find the link for Black's draft. Chuck please advise. >=20 > There were a number of LAN attributes proposed in these two=20 > drafts. Some of the attributes were already taken into=20 > separate drafts like location information and network=20 > bandwidth authorization. However, we need to scrub the=20 > remaining of attributes. =20 >=20 > 4) There were two drafts on location information (adrangi and jones > drafts) -- these drafts were moved to the GeoPriv WG. We are=20 > currently working on a combined draft -- plan to submit it=20 > in a few weeks. For those folks who are interested, please=20 > subscribe to GeoPriv mailing list. >=20 > Did I miss anything? >=20 > BR, > Farid >=20 >=20 >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > > Sent: Monday, May 03, 2004 2:30 PM > > To: radiusext@ops.ietf.org > > Subject: RE: RADIUS drafts review -- LAN attributes > >=20 > >=20 > >=20 > > > In the last BoF, a number of people volunteered to be > > reviewer for LAN > > > attribute drafts. > >=20 > > Farid, would you please remind us where the most current > > version of this draft is posted? Thanks! > >=20 > > -- Dave > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > > a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 16:42:56 +0000 Message-ID: <4097C7FD.CC1F1939@alcatel.be> Date: Tue, 04 May 2004 18:42:37 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: redirection+prepaid Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I was wondering how the redirection in draft-lior-radius-redirection-00 can be used for prepaid: the filters/redirect is applied by the NAS as soon the attributes are received by the NAS (either in access accept or CoA). How can this then be used for prepaid when the filters have to be applied when there is no quota anymore? Would it not be better to add something to indicate when it has to be applied (e.g., immediately, when no quota anymore, ...)? regards, Stefaan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 16:15:48 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 09:15:23 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQx4Eo4cfN8hZkxRbGXv4I9ulETywAA7dLwAAGE3WA= From: "Adrangi, Farid" To: "Nelson, David" , Cc: > Jari writes... >=20 >=20 > > Can you remind me why there is a dependency on the=20 > guidelines and WLAN=20 > > attributes? >=20 > I think this thread is discussing the LAN attributes draft,=20 > although there may not be a significant distinction. >=20 [FA] There is no distinction at all. I think there was a consensus to put all attributes under a generic name, LAN attributes. [/FA] > > I had been assuming that the guidelines > > are needed if you do something complicated, like subattributes or=20 > > SDO-specific attributes. But I'm not sure we need them for the WLAN=20 > > attrs draft. >=20 > I'm not sure, either. I guess that depends on how the draft=20 > shapes up. I simply hold that out as a possibility. I would=20 > like to see work on the design guidelines begin immediately=20 > (in parallel with other work) and would be willing to assist=20 > with that draft myself. [FA] I don't think we need design guidelines for LAN attributes (including WLAN) -- because as Jari said this is not a complicated task. Could you be more specific what you have in mind for design guidelines? We spent over 6 month arguing about subtypes -- and if we spend another 6 month arguing the design guidelines, for sure we will never get this done! BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 15:46:27 +0000 Message-ID: <4097BAB7.D6559C77@alcatel.be> Date: Tue, 04 May 2004 17:46:00 +0200 From: Nagi Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: "Nelson, David" CC: jari.arkko@piuha.net, radiusext@ops.ietf.org Subject: Re: RADIUS drafts review -- LAN attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > I had been assuming that the guidelines > > are needed if you do something complicated, like subattributes > > or SDO-specific attributes. But I'm not sure we need them > > for the WLAN attrs draft. > > I'm not sure, either. I guess that depends on how the draft shapes up. > I simply hold that out as a possibility. I would like to see work on > the design guidelines begin immediately (in parallel with other work) > and would be willing to assist with that draft myself. There seems to be a handful of LAN attributes and a few more might be needed in future. Also I presume the guidelines draft documents the structure of SubAttributes. It looks as if there is a dependency in case the LAN attributes belong to SubAttributes category. This is debatable in contrast with the *flat* LAN attributes. regards Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 14:48:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 10:42:29 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQx4Eo4cfN8hZkxRbGXv4I9ulETywAA7dLw From: "Nelson, David" To: Cc: Jari writes... > This would make it be late from, say, 3GPP release 6 specifications > which probably would like to refer to an IETF spec on this. We should, of course, be sensitive to the timing requirements of other SDOs. I know that there have been co-coordinating conference calls with 3GGP2 (hosted by Thomas Narten). Perhaps we need a similar coordination effort with 3GPP. > Can you remind me why there is a dependency on the guidelines > and WLAN attributes? I think this thread is discussing the LAN attributes draft, although there may not be a significant distinction. > I had been assuming that the guidelines > are needed if you do something complicated, like subattributes > or SDO-specific attributes. But I'm not sure we need them > for the WLAN attrs draft. I'm not sure, either. I guess that depends on how the draft shapes up. I simply hold that out as a possibility. I would like to see work on the design guidelines begin immediately (in parallel with other work) and would be willing to assist with that draft myself. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 14:03:26 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 17:03:14 +0300 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAIi4TEA== From: "Romascanu, Dan (Dan)" To: "Adrangi, Farid" , Cc: "Nelson, David" Farid, draft-adrangi-radius-extension-for-pwlan-00.txt is expired and not = available any longer in the IETF repository. I guess that you intent to = re-submit it, as you are requiring comments. Do you have an alternative = URL to access it meantime? Thanks and Regards, Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid > Sent: 04 May, 2004 1:04 AM > To: radiusext@ops.ietf.org > Cc: Nelson, David > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 > Hi David, all >=20 > There are a number of drafts on LAN attributes: >=20 > 1) > http://www.ietf.org/internet-drafts/draft-lior-radius-redirect > ion-00.txt >=20 > 2) > http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandw > idth-capab > ility-00.txt >=20 > 3) There were two original drafts on LAN attributes: black and adrangi > drafts: > http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten sion-for-p wlan-00.txt Note : Couldn't find the link for Black's draft. Chuck please advise. There were a number of LAN attributes proposed in these two drafts. Some of the attributes were already taken into separate drafts like location information and network bandwidth authorization. However, we need to scrub the remaining of attributes. =20 4) There were two drafts on location information (adrangi and jones drafts) -- these drafts were moved to the GeoPriv WG. We are currently working on a combined draft -- plan to submit it in a few weeks. For those folks who are interested, please subscribe to GeoPriv mailing list. Did I miss anything? BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, May 03, 2004 2:30 PM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 >=20 > > In the last BoF, a number of people volunteered to be=20 > reviewer for LAN=20 > > attribute drafts. >=20 > Farid, would you please remind us where the most current=20 > version of this draft is posted? Thanks! >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 14:01:34 +0000 Message-ID: <4097A165.201@piuha.net> Date: Tue, 04 May 2004 16:57:57 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS drafts review -- LAN attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > Farid writes... > > >>I think everyone should participate in scrubbing the LAN attributes, > > and > >>help finalize their definition, format/syntax ... Whether or not we >>need a single or multiple drafts to express these attributes, we can >>discuss it in parallel. I think our primary focus should be to > > identify > >>a list of LAN attributes that we need to standardize, and work on > > their > >>definition. Your comment? > > > That sounds fine. If we can organize that effort to occur on the list, > and we have some active participants, then let's start... Actual > editing of the drafts will still require an individual to act as editor, > of course. > > Keep in mind, however, the WG work items and milestones from the draft > charter. > > Dec 04 Updated RADIUS MIBs submitted for publication. > Dec 04 RADIUS design guidelines submitted as an Informational RFC. > Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard > RFC. > Feb 05 RADIUS implementation issues and fixes submitted as an > Informational RFC. > Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC. > Feb 05 RFC 2486bis submitted as a Proposed Standard. > Dec 05 LAN attributes draft submitted as a Proposed Standard RFC. > Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. > > Before we can close on the LAN Attributes draft (or others) we need to > complete the design guidelines draft. Certainly, we can work in > parallel, to the extent that resources permit. The LAN Attributes draft > is scheduled to be completed in December of 2005. This would make it be late from, say, 3GPP release 6 specifications which probably would like to refer to an IETF spec on this. Can you remind me why there is a dependency on the guidelines and WLAN attributes? I had been assuming that the guidelines are needed if you do something complicated, like subattributes or SDO-specific attributes. But I'm not sure we need them for the WLAN attrs draft. Or I would hope we can get by without them -- maybe I'm mistaken. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 May 2004 13:44:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Tue, 4 May 2004 09:44:08 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAARSDQAAASEHQAB+DLtA= From: "Nelson, David" To: Farid writes... > I think everyone should participate in scrubbing the LAN attributes, and > help finalize their definition, format/syntax ... Whether or not we > need a single or multiple drafts to express these attributes, we can > discuss it in parallel. I think our primary focus should be to identify > a list of LAN attributes that we need to standardize, and work on their > definition. Your comment? That sounds fine. If we can organize that effort to occur on the list, and we have some active participants, then let's start... Actual editing of the drafts will still require an individual to act as editor, of course. Keep in mind, however, the WG work items and milestones from the draft charter. Dec 04 Updated RADIUS MIBs submitted for publication. Dec 04 RADIUS design guidelines submitted as an Informational RFC. Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard RFC. Feb 05 RADIUS implementation issues and fixes submitted as an Informational RFC. Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec 05 LAN attributes draft submitted as a Proposed Standard RFC. Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. Before we can close on the LAN Attributes draft (or others) we need to complete the design guidelines draft. Certainly, we can work in parallel, to the extent that resources permit. The LAN Attributes draft is scheduled to be completed in December of 2005. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 22:33:40 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 15:30:24 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAARSDQAAASEHQ From: "Adrangi, Farid" To: "Nelson, David" , Hi Dave, all >=20 > Looking back in the mail archives, there was discussion of=20 > setting up a relatively small "design team" to work on=20 > scrubbing and merging these various LAN attributes drafts. =20 > Is that still a viable approach for us to take? > =20 I think everyone should participate in scrubbing the LAN attributes, and help finalize their definition, format/syntax ... Whether or not we need a single or multiple drafts to express these attributes, we can discuss it in parallel. I think our primary focus should be to identify a list of LAN attributes that we need to standardize, and work on their definition. Your comment? BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 22:16:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 18:16:20 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAARSDQA== From: "Nelson, David" To: > Note : Couldn't find the link for Black's draft. Chuck please advise. I couldn't find it either... =20 > There were a number of LAN attributes proposed in these two drafts. > Some of the attributes were already taken into separate drafts like > location information and network bandwidth authorization. However, we > need to scrub the remaining of attributes. Looking back in the mail archives, there was discussion of setting up a relatively small "design team" to work on scrubbing and merging these various LAN attributes drafts. Is that still a viable approach for us to take? =20 > 4) There were two drafts on location information (adrangi and jones > drafts) -- these drafts were moved to the GeoPriv WG. We are currently > working on a combined draft -- plan to submit it in a few weeks. For > those folks who are interested, please subscribe to GeoPriv mailing > list. Yes. That's a good idea. Some level of cross-review will be required. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 22:13:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 15:13:50 -0700 Message-ID: <32C185DE9BB4A14097201167267EBE4019F87F@cacexc07.americas.cpqcorp.net> Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiAAAPDfUA== From: "Black, Chuck A" To: Here is the link to the original version of the 'black' draft for LAN Edge attributes: http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt. =20 As Farid mentions, since that time there has been some discussion regarding having separate drafts for attributes such as bandwidth and location. This original draft still contains those attributes. /chuck -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Adrangi, Farid Sent: Monday, May 03, 2004 3:04 PM To: radiusext@ops.ietf.org Cc: Nelson, David Subject: RE: RADIUS drafts review -- LAN attributes Hi David, all There are a number of drafts on LAN attributes: 1) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt 2) http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab ility-00.txt 3) There were two original drafts on LAN attributes: black and adrangi drafts: http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p wlan-00.txt Note : Couldn't find the link for Black's draft. Chuck please advise. There were a number of LAN attributes proposed in these two drafts. Some of the attributes were already taken into separate drafts like location information and network bandwidth authorization. However, we need to scrub the remaining of attributes. =20 4) There were two drafts on location information (adrangi and jones drafts) -- these drafts were moved to the GeoPriv WG. We are currently working on a combined draft -- plan to submit it in a few weeks. For those folks who are interested, please subscribe to GeoPriv mailing list. Did I miss anything? BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, May 03, 2004 2:30 PM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 >=20 > > In the last BoF, a number of people volunteered to be > reviewer for LAN > > attribute drafts. >=20 > Farid, would you please remind us where the most current version of=20 > this draft is posted? Thanks! >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single > line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 22:13:04 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 15:12:28 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAhe/AAAAmS7AAAPbLoA== From: "Adrangi, Farid" To: "Nelson, David" , Yes, of course. The more reviewers the better! I mentioned a list of people who already expressed interest and made a commitment -- i.e., they will review the drafts and post their comments to the list before the specified deadline. This does not preclude other people in the mailing list. BTW, I think I missed the following names in the reviewers list: Chuck Black & Farooq Bari. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, May 03, 2004 2:42 PM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 > > Hi Farid, > >=20 > > I was missed the last IETF meeting but can you include me=20 > in the list > of > > reviewers ? >=20 > At the risk of stating the obvious, it would seem to me that=20 > everyone subscribed to this mailing list is a reviewer, to=20 > one extent or another. Right? Or am I missing some point? >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 22:04:56 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 15:04:24 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfogAAB7GiA= From: "Adrangi, Farid" To: Cc: "Nelson, David" Hi David, all There are a number of drafts on LAN attributes: 1) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt 2) http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab ility-00.txt 3) There were two original drafts on LAN attributes: black and adrangi drafts: http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p wlan-00.txt Note : Couldn't find the link for Black's draft. Chuck please advise. There were a number of LAN attributes proposed in these two drafts. Some of the attributes were already taken into separate drafts like location information and network bandwidth authorization. However, we need to scrub the remaining of attributes. =20 4) There were two drafts on location information (adrangi and jones drafts) -- these drafts were moved to the GeoPriv WG. We are currently working on a combined draft -- plan to submit it in a few weeks. For those folks who are interested, please subscribe to GeoPriv mailing list. Did I miss anything? BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, May 03, 2004 2:30 PM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS drafts review -- LAN attributes >=20 >=20 >=20 > > In the last BoF, a number of people volunteered to be=20 > reviewer for LAN=20 > > attribute drafts. >=20 > Farid, would you please remind us where the most current=20 > version of this draft is posted? Thanks! >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:56:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 17:56:10 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAhe/AAAAmS7AAADzt0AAAQgrQ From: "Nelson, David" To: > ...I was responding to Farid's email that had a list=20 > of volunteer reviewer names (did not exactly know what > the list meant). Nor did I. I assume these are folks who volunteered to *actively* review the draft(s) on this mailing list. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:51:59 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 14:51:43 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAhe/AAAAmS7AAADzt0A== From: "Bari, Farooq" To: "Nelson, David" , Completely agree with your statement - I was responding to Farid's email that had a list of volunteer reviewer names (did not exactly know what the list meant). -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David Sent: Monday, May 03, 2004 2:42 PM To: radiusext@ops.ietf.org Subject: RE: RADIUS drafts review -- LAN attributes > Hi Farid, >=20 > I was missed the last IETF meeting but can you include me in the list of > reviewers ? At the risk of stating the obvious, it would seem to me that everyone subscribed to this mailing list is a reviewer, to one extent or another. Right? Or am I missing some point? -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:41:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 17:41:47 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAhe/AAAAmS7A= From: "Nelson, David" To: > Hi Farid, >=20 > I was missed the last IETF meeting but can you include me in the list of > reviewers ? At the risk of stating the obvious, it would seem to me that everyone subscribed to this mailing list is a reviewer, to one extent or another. Right? Or am I missing some point? -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:35:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 14:35:03 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAhe/A From: "Bari, Farooq" To: "Adrangi, Farid" , Hi Farid, I was missed the last IETF meeting but can you include me in the list of reviewers ? BR, Farooq -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Adrangi, Farid Sent: Monday, May 03, 2004 2:19 PM To: radiusext@ops.ietf.org Subject: RADIUS drafts review -- LAN attributes Hi, In the last BoF, a number of people volunteered to be reviewer for LAN attribute drafts. These people are: Jari Arkko, Pasi Eronen, Osok Song, Parviz Yegani, David Mariblanca, Farid Adrangi, and Avi Lior, and lionel Morand I think we should start this process ASAP - we can start with two more drafts at a time and set a deadline for completing the review. Is this reasonable? Do you have any suggestions how to proceed? BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:30:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 17:30:02 -0400 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQAAVfog From: "Nelson, David" To: > In the last BoF, a number of people volunteered to be reviewer for LAN > attribute drafts. Farid, would you please remind us where the most current version of this draft is posted? Thanks! -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 May 2004 21:19:25 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RADIUS drafts review -- LAN attributes Date: Mon, 3 May 2004 14:18:52 -0700 Message-ID: Thread-Topic: RADIUS drafts review -- LAN attributes Thread-Index: AcQxVDvQlvUveswpQ76a/N3wF+z5rQ== From: "Adrangi, Farid" To: Hi, In the last BoF, a number of people volunteered to be reviewer for LAN attribute drafts. These people are: Jari Arkko, Pasi Eronen, Osok Song, Parviz Yegani, David Mariblanca, Farid Adrangi, and Avi Lior, and lionel Morand I think we should start this process ASAP - we can start with two more drafts at a time and set a deadline for completing the review. Is this reasonable? Do you have any suggestions how to proceed? BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: