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

GangChen <> Thu, 21 February 2013 05:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E90AF21E809C for <>; Wed, 20 Feb 2013 21:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.136
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AfXvUqxayUxS for <>; Wed, 20 Feb 2013 21:39:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8B1EC21E809E for <>; Wed, 20 Feb 2013 21:39:35 -0800 (PST)
Received: by with SMTP id j8so2823706qah.14 for <>; Wed, 20 Feb 2013 21:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id x8mr11702754qey.5.1361425174937; Wed, 20 Feb 2013 21:39:34 -0800 (PST)
Received: by with HTTP; Wed, 20 Feb 2013 21:39:34 -0800 (PST)
In-Reply-To: <0f2e01ce0556$6698cf60$33ca6e20$>
References: <0f2e01ce0556$6698cf60$33ca6e20$>
Date: Thu, 21 Feb 2013 13:39:34 +0800
Message-ID: <>
From: GangChen <>
To: Dan Wing <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: mif <>, draft-ietf-mif-happy-eyeballs-extension <>
Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Feb 2013 05:39:39 -0000

2013/2/8, Dan Wing <>om>:
>> -----Original Message-----
>> From: [] 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 <> 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
> which queries and needs to see 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
> 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


> 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