Re: [mif] DNS selection with HE-MIF

GangChen <phdgang@gmail.com> Wed, 06 February 2013 07:29 UTC

Return-Path: <phdgang@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3521F8921 for <mif@ietfa.amsl.com>; Tue, 5 Feb 2013 23:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.53
X-Spam-Level:
X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th2Iwcmd7Bd5 for <mif@ietfa.amsl.com>; Tue, 5 Feb 2013 23:29:07 -0800 (PST)
Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id F034C21F8900 for <mif@ietf.org>; Tue, 5 Feb 2013 23:29:06 -0800 (PST)
Received: by mail-qe0-f46.google.com with SMTP id 1so498420qec.5 for <mif@ietf.org>; Tue, 05 Feb 2013 23:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=z7B+WyGRBYhTUCqhXyQdZcp8d/LHqeX75Iz1VZaCI4g=; b=vOtFT0iA6cQECZ9q+TNGdMG4eC1p73CH1wVS1Qkk5T4QZ40SnaB01zo5jV9xPVrMg/ kJ32LWniJfy4FG411xrlfREVyAvO9MBtfYr6O92MzGGrgIcBJRpIzM481OpsafPOMlqB 5nWmD2QdBW4Sxy5B/8NBPYZvVZgpIgw/0uGRI/5wwvtUJ/l7voPuf1eHurq7oh8Zlhw0 8qmA1bIhSQu0lkaXsMbpsgeZ7apYlIyy2XkAn1Tw1ZS6zLAN5GJ7Ep8trMZoOQ6e8Tgz WsaN5quLzY8HB0GSAN+k+KdoS7VCO9P/DX2OBQjrvxQa3goNQHOPXmELWHhgH0ckbPhu Uwpw==
MIME-Version: 1.0
X-Received: by 10.224.207.72 with SMTP id fx8mr20808898qab.66.1360135746391; Tue, 05 Feb 2013 23:29:06 -0800 (PST)
Received: by 10.49.48.12 with HTTP; Tue, 5 Feb 2013 23:29:06 -0800 (PST)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com>
References: <CAM+vMERak2vAoYFeSLRep2xjpm480qPjutyv4-tV=KtU0XO=fw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <CAM+vMETvE==qUZO2_rhyUB+=ChUR4a9CoTCF+q=gBL2cRA+0UA@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <CAM+vMER=CPNpXTcrqOpGqEaH+GpA81pyH_D3Hja+1jQqNTNxqw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747D7F7@mbx-01.win.nominum.com> <CAM+vMESEiTOTHorbaqSEDbiKPV06Vt2pW3TAs8+Of4=mnVcbNA@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747F348@mbx-01.win.nominum.com> <CAM+vMERqcZy-748Sp46QTjVtfh_0JrWm8xNquG-vbZVYikO+Uw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747F7EF@mbx-01.win.nominum.com>
Date: Wed, 06 Feb 2013 15:29:06 +0800
Message-ID: <CAM+vMETf8z4opWYXLTCBv2+VTaoOWnpB9ziXgaXw0dxE6QF8Pw@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: mif <mif@ietf.org>, draft-ietf-mif-happy-eyeballs-extension <draft-ietf-mif-happy-eyeballs-extension@tools.ietf.org>
Subject: Re: [mif] DNS selection with HE-MIF
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 07:29:07 -0000

2013/2/5, Ted Lemon <Ted.Lemon@nominum.com>:
> On Feb 5, 2013, at 5:47 AM, GangChen <phdgang@gmail.com> wrote:
>> Ideally, HE-MIF could choose the right interface
>> matching the provisioning domain. However, if the interface in
>> provisioning domain A using default gw could reach the peer, it will
>> have a problem. I believe the problem is similar with
>> http://tools.ietf.org/html/rfc6731#section-2.3. The only solution is
>> manual user intervention as far as I can say.
>
> No, this is not true.   Furthermore, this failure mode happens to me on a
> regular basis when my handset connects to a Wifi SSID it recognizes;
> everything IP-dependent stops until I either disable WiFi or authenticate to
> the captive portal.  This is a trivially easy attack to do on handsets with
> WiFi (which is most handsets nowadays).
>
> Similarly, some web gateways, particularly in airports and hotels, only
> offer service on ports 80 and 443.  I'd like to be able to use this
> transport where it works, because it's cheaper than my 4G LTE service (at
> least hypothetically).   But a solution that follows the weak host model
> will not succeed in this situation—it will either always use LTE, or always
> use the WiFi.
>
> If HE-MIF does not address this use case, it seems to me that we simply
> aren't addressing the bulk of the use cases that motivated the formation of
> this working group.   If that's the case, why do the work?

I guess the information on this link may relieve your concerns.
http://www.ietf.org/mail-archive/web/mif/current/msg01138.html

I have tested hotspots in our network. The captive portal systems do
not reply with their own IP address, but reply with the IP
address of the queried FQDN, and then do IP masquerading  as the
destination IP address. It's using HTTP redirection to the captive portal.

In this way, HE-MIF would work well.
Since TCP handshake would be broken if there is a captive portal,
HE-MIF node would fallback to other interfaces automatically.

Best Regards

Gang