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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> 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.  

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