[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <dnelson@enterasys.com>
>>>Bernard Aboba <aboba@internaut.com>
>>>
>>>Operations and Management Area Director(s):
>>>David Kessens <david.kessens@nokia.com>
>>>Bert Wijnen <bwijnen@lucent.com>
>>>
>>>Operations and Management Area Advisor:
>>>David Kessens <david.kessens@nokia.com>
>>>
>>>Technical Advisor:
>>>Paul Congdon <paul_congdon@hp.com>
>>>
>>>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: <http://psg.com/lists/radiusext/>
>>>
>>>--
>>>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/>
>>>
>>
>>--
>>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/>
>>
>
--
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/>