Re: [mif] [MIF] captive portal was RE: [Editorial Errata Reported] RFC6418 (3057)

Le 2011-12-22 à 09:10, <pierrick.seite@orange.com> a écrit :

> 
> 
>> -----Message d'origine-----
>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
>> Simon Perreault
>> Envoyé : jeudi 22 décembre 2011 15:05
>> À : Ted Lemon
>> Cc : <mif@ietf.org>; <denghui02@hotmail.com>
>> Objet : Re: [mif] [Editorial Errata Reported] RFC6418 (3057)
>> 
>> On 2011-12-21 19:23, Ted Lemon wrote:
>>> Isn't this talking about captive portals? If so, then *after*
>> authentication you
>>> get unmodified DNS and HTTP; before authentication, you get forged
>> DNS responses
>>> that force you to the captive portal.
>> 
>> Just for the sake of discussion...
>> 
>> Captive portals that modify DNS responses are exceedingly rare.
>> Usually, captive
>> portals work by NATing the destination address of packets emitted from
>> clients
>> having an unauthenticated link-layer addresses. 
> 
> I'm not an expert in captive portals but I think NAT based solution is as rare as DNS based :-) Captive portal are usually based on HTTP redirection.

that is also my understanding: HTTP redirection is widely used.

Marc.

> 
> Pierrick
> 
> The reason, I presume,
>> is that
>> DNS responses get cached by the OS and/or application, so sending
>> "wrong" DNS
>> responses to clients just doesn't work well.
>> 
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif