IETF Logo Mail Archive

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

<pierrick.seite@orange.com> Thu, 22 December 2011 14:10 UTC

Return-Path: <pierrick.seite@orange.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0984A21F8B43 for <mif@ietfa.amsl.com>; Thu, 22 Dec 2011 06:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-pNIIDMIoCm for <mif@ietfa.amsl.com>; Thu, 22 Dec 2011 06:10:40 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id F204321F8B3C for <mif@ietf.org>; Thu, 22 Dec 2011 06:10:39 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1938E304B3; Thu, 22 Dec 2011 15:21:33 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B9664E30498; Thu, 22 Dec 2011 15:21:33 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 15:10:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Dec 2011 15:10:34 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB120@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4EF33927.6000306@viagenie.ca>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MIF] captive portal was RE: [mif] [Editorial Errata Reported] RFC6418 (3057)
Thread-Index: AczAstaJNyGaxm7CT1+dtGUFTQHbNwAADOHw
References: <20111222000527.5A49F72E004@rfc-editor.org><CC003F2F-4A8E-4A53-B854-49EB47DB83B8@lilacglade.org><AE3B6A20-80EA-49C4-82D7-79EC93873445@nominum.com> <4EF33927.6000306@viagenie.ca>
From: pierrick.seite@orange.com
To: simon.perreault@viagenie.ca, Ted.Lemon@nominum.com
X-OriginalArrivalTime: 22 Dec 2011 14:10:35.0295 (UTC) FILETIME=[794202F0:01CCC0B3]
Cc: denghui02@hotmail.com, mif@ietf.org
Subject: [mif] [MIF] captive portal was RE: [Editorial Errata Reported] RFC6418 (3057)
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2011 14:10:41 -0000

> -----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.

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

v2.23.0 | Report a Bug | By Email