Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks
"Charles E. Perkins" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Organization | Wichorus Inc. |
| Message-ID | <[email protected]> |
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<[email protected]> 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 >> <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/mext >> >