Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks

Pete McCann <mccap@petoni.org> Thu, 25 August 2011 20:54 UTC

Return-Path: <mccap@petoni.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 3ABB821F8C6C for <mext@ietfa.amsl.com>; Thu, 25 Aug 2011 13:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 W-lxTH+f4cTC for <mext@ietfa.amsl.com>; Thu, 25 Aug 2011 13:54:48 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 365D621F8B7C for <mext@ietf.org>; Thu, 25 Aug 2011 13:54:48 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2272001fxe.31 for <mext@ietf.org>; Thu, 25 Aug 2011 13:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TVoaWcW7/chOXAAclO22lXxQ4Z6luzNA5cgsr/PHaUw=; b=UzuMwOy3+TW2TBe9oJqntUBUL6dVLrvu5UTWqFhxXzR1EU6rtPb8Rl5W8Uc+ZSfenO jgz5kFchYrQi6/sHgH4sJbUl/CWQwcy9eQlVPC9h1xxIYdVIuiHkvF7jIjsyLnTgTKl2 3dhOHB2RWtIkc3SW40U1A0B6m5zzWI/p5G2Us=
MIME-Version: 1.0
Received: by 10.223.91.147 with SMTP id n19mr316859fam.53.1314305761797; Thu, 25 Aug 2011 13:56:01 -0700 (PDT)
Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 13:56:01 -0700 (PDT)
X-Originating-IP: [4.28.5.163]
In-Reply-To: <4E56AF52.3070306@computer.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> <4E56AF52.3070306@computer.org>
Date: Thu, 25 Aug 2011 16:56:01 -0400
Message-ID: <CACvMsLFZAHx6yz7OAbrK3YtTf1WJLKURZfh49ONEoqWj5UTBaQ@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: charliep@computer.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
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:54:49 -0000

Hi, Charlie,

On Thu, Aug 25, 2011 at 4:23 PM, Charles E. Perkins
<charliep@computer.org> wrote:
>
> 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)

Some agent somewhere has to know it prior to binding it to a
home address.

> - The access network does not have to complete the
>  assignment of the care-of address until it has
>  verified the authentication

What do you mean by "complete"?

> - 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.

I assume a visited network would allocate at least
a /64 and probably more (a shorter prefix) if it wanted
to enable NEMO.  Depending on the amount of address
space allocated to that particular point of attachment,
I could imagine it being quickly exhausted by an attacker
that didn't have to pass authentication.  And given that
cells are getting smaller and more numerous, there will
be less and less address space allocated to each one.

> 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.

If we could simply convince 3GPP operators to allow direct
Internet access as the default option (in the LIPA style) I
think it would tend to dramatically cut down on the complex
interfaces.  Right now the default option seems to be home-routed
traffic and hiding mobility from the UE as much as possible.

> 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.

It would be nice if EAP could be used as an air interface authentication
method in an LTE network.  If we had that and direct LIPA style connectivity
it would be possible to build something interesting on top.

-Pete