2013/2/8, Dan Wing <dw...@cisco.com>: >> -----Original Message----- >> From: mif-boun...@ietf.org [mailto:mif-boun...@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 <phdg...@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 > > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
