Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF]

GangChen <phdgang@gmail.com> Thu, 21 February 2013 05:39 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 E90AF21E809C for <mif@ietfa.amsl.com>; Wed, 20 Feb 2013 21:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.136
X-Spam-Level:
X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
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 AfXvUqxayUxS for <mif@ietfa.amsl.com>; Wed, 20 Feb 2013 21:39:36 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1EC21E809E for <mif@ietf.org>; Wed, 20 Feb 2013 21:39:35 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id j8so2823706qah.14 for <mif@ietf.org>; Wed, 20 Feb 2013 21:39:35 -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; bh=OYYs6FYG1Y2NAKvpB9jGsFqi26budNrP28+j1x07h6Y=; b=BsjZ+479PAHDFKV73vgyge+JX2JfJXB7zjxIXY3p0lk060dbomO/FJNlt3CVCHISfp Jg+78n5OJ9947IAhoQb9vLQIZ3/MdIHSgpvnh0rPwyJhovu26SgAM/tLnBwHhZ6ZF8mF WGx8eNEv5aQYYhyd8YTinBYCfzXyBRr7d/vbU+GryVQwYY7yOfYdKLryCDv6l3GVSjgV Tvig4Q9LnCDSVCqjfiG8CXh7hrVT2XfhhaSeIr8yXuwzbRdjlWL2cvGDNKux1AKBy6dG inGYRGFCVHZAhtz0dJKF4vMPng8MS2FB/POlFNqM75/u0/VFOQb1brPVFpfbrHPc+7aV lF7Q==
MIME-Version: 1.0
X-Received: by 10.49.84.104 with SMTP id x8mr11702754qey.5.1361425174937; Wed, 20 Feb 2013 21:39:34 -0800 (PST)
Received: by 10.49.48.12 with HTTP; Wed, 20 Feb 2013 21:39:34 -0800 (PST)
In-Reply-To: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com>
References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com>
Date: Thu, 21 Feb 2013 13:39:34 +0800
Message-ID: <CAM+vMETMK2+4t1pPOrVmTqksGrFFWrH9t-gN7cGCRSTp4QtsdA@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: mif <mif@ietf.org>, draft-ietf-mif-happy-eyeballs-extension <draft-ietf-mif-happy-eyeballs-extension@tools.ietf.org>
Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: 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: Thu, 21 Feb 2013 05:39:39 -0000

2013/2/8, Dan Wing <dwing@cisco.com>om>:
>> -----Original Message-----
>> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
>> Ted Lemon
>> Sent: Monday, February 04, 2013 9:35 PM
>> To: GangChen
>> Cc: mif; draft-ietf-mif-happy-eyeballs-extension
>> Subject: Re: [mif] DNS selection with HE-MIF
>>
>> On Feb 4, 2013, at 11:02 PM, GangChen <phdgang@gmail.com> wrote:
>> > I can't comment on benefits of "doing DNS queries within one
>> > provisioning domain, and then using the results in the other
>> > provisioning domain." But HE-MIF has to do in some cases, because that
>> > maybe a normal node behavior, like stated in RFC6418 "A node usually
>> > has a node-scoped routing table". This issue may retrospect to basic
>> > Internet host design in RFC1122. Changing the model would go beyond
>> > HE-MIF scope.
>>
>> Okay, so your point is that we can't do connections within a
>> provisioning domain, because we don't have control over how a connection
>> is routed.
>>
>> I agree that this is a problem, but it is explicitly within the scope of
>> the MIF charter to consider this problem and document it.   It is quite
>> likely the case that solving the problem is outside of the current MIF
>> charter, and that such work, if attempted, ought not to occur in MIF.
>>
>> However, if in fact the HE-MIF document can't work correctly without
>> solving this problem, then it is certainly within the scope of the
>> current charter for the MIF working group to draw that conclusion.
>>
>> For my part, what I am saying is that HE-MIF can't really be very useful
>> without solving this problem.   It is not in fact the case that a MIF
>> node can have a single node-scoped routing table and still succeed in
>> communicating on the network in the face of, for example, an interface
>> that's connected to a captive portal but providing a default route, as
>> such captive portals typically do.
>
> The technique used by both Apple and Microsoft is, when joining a new
> network, to attempt to retrieve a certain URI.  Microsoft's procedure
> is described in
> http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx,
> which queries www.msftncsi.com and needs to see 131.107.255.255 as
> the answer, and then does an HTTP GET.  If anything is abnormal, it
> assumes there is a proxy on the path.  Apple does something similar by
> attempting to retrieve https://www.apple.com/library/test/success.html.
> Unfortunately, this seems the best technique available to detect such
> DNS interception and HTTP interception proxies that force a login or
> force a click-through.

Thanks for providing the information.
I guess that could be a way to resolve the issue of captive portal
with DNS selections.
Let's see,

Those network connectivity probes could be performed prior to
DNS-selections. A captive portal would likely fail to pass the
examination. The interface can be declared as "down" unless users pass
the authentication. HE-MIF could therefore be able to automatically
rely upon other interfaces to select DNS server by excluding the
un-examined interfaces.

Best Regards

Gang


> For MIF -- not just HE-MIF, but all of MIF -- we should not declare an
> interface "up" until such a validation succeeds.  It is unfortunate
> this is not solved at layer 2, where it arguably belongs.
>
> -d
>
>
>