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

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Feb 2013 09:13:08 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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 <[email-masked]> 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

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Feb 2013 12:52:47 -0500

> this is not solved at layer 2, where it arguably belongs.

Would it be worthwhile for MIF to start making a list of things that 
really need solutions elsewhere?   Even if there are hacks or heuristics 
that are used in the absence of such solutions?

Keith

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 7 Feb 2013 14:59:06 -0600

> that are used in the absence of such solutions?

I would certainly think that should be a good idea.

Will

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Feb 2013 08:48:54 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    >> 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.

    Keith> Would it be worthwhile for MIF to start making a list of
    Keith> things that really need solutions elsewhere?  Even if there
    Keith> are hacks or heuristics that are used in the absence of such
    Keith> solutions?

Yes.

In the portal case, we need a DHCP "login required" message.
It would be nice if we also had a BCP on how to signal and upgrade
From HTTP login to some DHCP EAP, perhaps using a EAP-TLS resume 
From the HTTP session state.  This would permit captive portals to 
recognize re-logins.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Feb 2013 14:50:18 +0000

> that are used in the absence of such solutions?

The MS hack does a WGET on http://www.msftncsi.com/ncsi.txt and requires
the correct text to be returned.

An extension is http://ipv6.msftncsi.com/ncsi.txt, used to verify IPv6ness.
It's supposed to resolve to 2001:450:2002:384::40d6:ce0b and again return
the correct text.

[Thanks to Dan Wing over on another list for this info.]

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Feb 2013 18:12:10 +0100

> In the portal case, we need a DHCP "login required" message.

YEs, tool useful.

Or an ARP reply message which could carry same "login required".  This
could be sent by the default router to the Client when it presents its
MAC address.

Rather ARP than DHCP because the end effect of the portal authentication
is the opening of a firewall filter which is based on the MAC address.
ARP is at the same level.

> From the HTTP session state.  This would permit captive portals to

Same with ARP...

Alex

>
>
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 8 Feb 2013 12:14:15 -0500

> In the portal case, we need a DHCP "login required" message.

specially in more open portals, IPv6 deployments may use RA, so it has to also involve RA.

Marc.

> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: GangChen <[email-masked]>
Date: Thu, 21 Feb 2013 13:39:34 +0800

> DNS interception and HTTP interception proxies that force a login or

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