[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS-Mobile IP support??: RADEXT WG Charter
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 <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/>
--
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/>