Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks
"Charles E. Perkins" <charliep@computer.org> Thu, 25 August 2011 20:22 UTC
Return-Path: <charliep@computer.org>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 26BDA21F8B79 for <mext@ietfa.amsl.com>;
Thu, 25 Aug 2011 13:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,
BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtWOSo+pc8e9 for
<mext@ietfa.amsl.com>; Thu, 25 Aug 2011 13:22:37 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net
(elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com
(Postfix) with ESMTP id 173A621F8B76 for <mext@ietf.org>;
Thu, 25 Aug 2011 13:22:37 -0700 (PDT)
Received: from [138.111.58.2] (helo=[172.17.96.89]) by
elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.67) (envelope-from <charliep@computer.org>) id 1QwgSq-0005n4-B0;
Thu, 25 Aug 2011 16:23:48 -0400
Message-ID: <4E56AF52.3070306@computer.org>
Date: Thu, 25 Aug 2011 13:23:46 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Pete McCann <mccap@petoni.org>, Alper Yegin <alper.yegin@yegin.org>
References: <4E554BAA.9080409@computer.org><CAE_dhjtz5ue1noQwzb5gcCFa1gq_4EY-hxMhQRL07JAQNZq3bg@mail.gmail.com><CACvMsLEgYZ+z05x9O978OuRG+fn=EqspPxjiBfV5VB2UvS0wWg@mail.gmail.com><4E56A052.1000604@computer.org>
<CACvMsLHnBrOyfcy62ncxidenfC6KsqmhEHvikFLSx4WDNVJcfQ@mail.gmail.com>
In-Reply-To: <CACvMsLHnBrOyfcy62ncxidenfC6KsqmhEHvikFLSx4WDNVJcfQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ecb476500cdd476d5055a9ae9a07b1a4350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 138.111.58.2
Cc: mext <mext@ietf.org>
Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc.
in wireless networks
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: charliep@computer.org
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>,
<mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2011 20:22:38 -0000
Hello Pete, Your analysis of operator concerns is quite correct, it seems to me, but on the other hand maybe the IETF would be able to alleviate operator concerns once they are properly understood. And, if operators could be assured that they would suffer no harm by following some revised IETF protocol steps, there would be a good chance for progress. Address assignment is perhaps the stickiest case. Here are some observations: - The UE doesn't necessarily have to know its care-of address until after handover is complete (and, according to [netext], not even then) - The access network does not have to complete the assignment of the care-of address until it has verified the authentication - As mentioned before, the home agent is a viable candidate for AAA relay, actually appearing as the AAA server to the access network - An IPv6 address can't really be considered a valuable resource if it isn't routable, and so even if UE knew its IPv6 care-of address, it would not get any benefit until authentication completes. If there is any disagreement about these points, I would be surprised, but every day brings new surprises. I am proposing that we should try to make a higher-performance handover specification that is less complicated than, say, S101/S102/S103. Almost anything the IETF could possibly do would be less complicated than those, and I fully expect much easier to configure, administer, and operate. So, the problem statement could be: Enable Mobile IP to provide high-performance mobility management that is better able to be deployed in modern wireless access networks that already utilize alternate access authentication protocols. Determine the suitability of network-based versus client-based variations of the candidate solutions. Regards, Charlie P. On 8/25/2011 12:54 PM, Pete McCann wrote: > Hi, Charlie, > > The problem seems to be we have the following three steps that have > to be carried out in order: > > 1) access authentication > 2) address assignment > 3) mobility management > > (3) depends on (2) because you can't bind your home address to a > care-of address until you have a care-of address. (2) depends on (1) > because operators don't like to give out resources until they know they > will get paid. > > It's possible to combine all these things into one protocol (perhaps PANA > could have been that vehicle, if certain decisions had not been made) but > the IETF seems to like breaking problems down into layered solutions. > > -Pete > > On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins > <charliep@computer.org> wrote: >> Hello Pete, >> >> Yes, putting Mobile IP inside of EAP would be one approach. >> It would have some interesting advantages. Other approaches >> might be more properly done in [netext] -- or perhaps have >> already been looked; I could have possibly missed some of >> the relevant discussion there. >> >> Regards, >> Charlie P. >> >> >> >> On 8/25/2011 11:40 AM, Pete McCann wrote: >>> >>> Hi, Julien, >>> >>> Are you talking about EAP inside IKEv2? That presupposes that the MN >>> is already attached to the network somewhere and has an IP address (i.e., >>> it has already passed access authentication). >>> >>> It may be interesting to look at whether access authentication and >>> mobility >>> management can be combined. For example, we could put Mobile IP (or >>> some variant of it) inside an EAP exchange used for access authentication. >>> Charlie, are you proposing something like this? >>> >>> -Pete >>> >>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier<julien.ietf@gmail.com> >>> wrote: >>>> >>>> Charlie, >>>> >>>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>>> can already mutually authenticate using EAP, and this is incidentally >>>> what 3GPP leverages on, together with the EAP-AKA method. What is >>>> missing? >>>> >>>> --julien >>>> >>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>>> <charliep@computer.org> wrote: >>>>> >>>>> Hello folks, >>>>> >>>>> It's now 2011. Mobile IP was standardized late in >>>>> 1996, after work had already been started nearly >>>>> ten years before. Over two decades! -- and regardless >>>>> of lip service to fixed/mobile convergence we still >>>>> don't have seamless mobility in user devices across >>>>> heterogeneous media, and standards organizations >>>>> (notably 3GPP) are not properly taking advantage of >>>>> what Mobile IP can do. The losers are the end-users, >>>>> which means all of us. >>>>> >>>>> There are many reasons for this, but one of the >>>>> main reasons has to do with authentication at the >>>>> access network. EAP in various forms is being >>>>> utilized for this purpose, and Mobile IP is not, >>>>> even though there has never been any reported >>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>>> (to my knowledge). Moreover, unless there is >>>>> something wrong with the cryptography that also >>>>> has not been reported, these authentication methods >>>>> enable _mutual_ authentication between the network >>>>> and the client, not just client authentication. >>>>> >>>>> In order for Mobile IP to enable the real promise >>>>> of high performance heterogeneous networking, we >>>>> have to do some more work. I would like to initiate >>>>> some more discussion about this. DMM is interesting >>>>> in its own right, but it's not at all the whole >>>>> story. Moreover, with proper design, it is likely >>>>> the supposed burden of signaling to the home agent >>>>> can be substantially reduced. As one simple example, >>>>> if handovers are accomplished locally between trusted >>>>> access agents (routers, 802.11 access controllers, ...) >>>>> then the actual timing of tunnel redirection from the >>>>> home agent becomes much less critical. This is also >>>>> intricately intertwined with authentication. >>>>> >>>>> If the Home Agent were recognized as a robust security >>>>> appliance, then it could naturally sit on the network >>>>> boundary as an IP-addressable device. Mobile IP >>>>> authentication could become the primary means of >>>>> validating user access, instead of an afterthought >>>>> to enable IP-address preservation after all the heavy >>>>> lifting has been done a lower levels. >>>>> >>>>> I would like to propose that in this working group we >>>>> should go about making this happen. It seems to be >>>>> important, and undeniably aligned with our working >>>>> group responsibilities. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> >
- [MEXT] Well-known problem with authentication/etc… Charles E. Perkins
- Re: [MEXT] Well-known problem with authentication… Alper Yegin
- Re: [MEXT] Well-known problem with authentication… Charles E. Perkins
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Pete McCann
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Charles E. Perkins
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Alper Yegin
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Pete McCann
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Basavaraj.Patil
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Pete McCann
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Charles E. Perkins
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Jong-Hyouk Lee
- Re: [MEXT] Well-known problem with authentication… Basavaraj.Patil
- Re: [MEXT] Well-known problem with authentication… Basavaraj.Patil
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Basavaraj.Patil
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Pete McCann
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Pete McCann
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Pete McCann
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Charles E. Perkins
- Re: [MEXT] Well-known problem with authentication… Basavaraj.Patil
- Re: [MEXT] Well-known problem with authentication… Charles E. Perkins
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Basavaraj.Patil
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Charles E. Perkins
- Re: [MEXT] Well-known problem with authentication… Basavaraj.Patil
- Re: [MEXT] Well-known problem with authentication… Julien Laganier
- Re: [MEXT] Well-known problem with authentication… Hesham Soliman
- Re: [MEXT] doubting a 3GPP MIP, because requires … Alexandru Petrescu
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Charles E. Perkins
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Charles E. Perkins
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Behcet Sarikaya
- Re: [MEXT] [!! SPAM] Re: Well-known problem witha… Charles E. Perkins
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Julien Laganier
- Re: [MEXT] [!! SPAM] Re: Well-known problem with … Pete McCann