IETF Logo Mail Archive

Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)

<pierrick.seite@orange-ftgroup.com> Wed, 13 April 2011 09:08 UTC

Return-Path: <pierrick.seite@orange-ftgroup.com>
X-Original-To: mif@ietfc.amsl.com
Delivered-To: mif@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00842E0674 for <mif@ietfc.amsl.com>; Wed, 13 Apr 2011 02:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFbUocNLQCBR for <mif@ietfc.amsl.com>; Wed, 13 Apr 2011 02:08:54 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfc.amsl.com (Postfix) with ESMTP id 49AB8E0689 for <mif@ietf.org>; Wed, 13 Apr 2011 02:08:54 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 73BDBFC400F; Wed, 13 Apr 2011 11:09:01 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 65BCBFC4008; Wed, 13 Apr 2011 11:09:01 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 11:08:53 +0200
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: Wed, 13 Apr 2011 11:08:52 +0200
Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A1676B@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)
Thread-Index: Acv5P9t2MQVWddu8SF6IOy4IoPwSkwAd3y2w
References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> <BANLkTinpZ0R7o5T_ALOYyok-8fFqkO41Rg@mail.gmail.com> <BANLkTincH80ye2Wm6heeJa8zDZXC7Yhraw@mail.gmail.com> <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com>
From: pierrick.seite@orange-ftgroup.com
To: Ted.Lemon@nominum.com, julien.ietf@gmail.com
X-OriginalArrivalTime: 13 Apr 2011 09:08:53.0499 (UTC) FILETIME=[693C64B0:01CBF9BA]
Cc: mif@ietf.org
Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)
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: Wed, 13 Apr 2011 09:08:55 -0000

I've checked on Orange hotspot, recent release, and it works as Julien said... Shame on me, I should have checked before... Anyway, the problem statement is not supposed to be exhaustive on mechanisms used by captive portal, but I've updated the document to clarify that DNS modification is not the only way to do redirection.

> -----Message d'origine-----
> De : Ted Lemon [mailto:Ted.Lemon@nominum.com]
> Envoyé : mardi 12 avril 2011 20:31
> À : Julien Laganier
> Cc : Hui Deng; SEITE Pierrick RD-RESA-REN; mif@ietf.org
> Objet : Re: [mif] prblem statement: DNS/captive portals - was (RE: AD
> review of draft-ietf-mif-current-practices)
> 
> On Apr 12, 2011, at 2:01 PM, Julien Laganier wrote:
> > On a side note, the captive portal systems I've encountered lately do
> > not reply with the IP address of the captive portal when queried with
> > an arbitrary FQDN (e.g. example.com), but rather reply with the IP
> > address of the queried FQDN, and then do IP masquerading as the
> > destination IP address when they receive a TCP SYN on port 80. When
> > the HTTP GET arrives, they operate an HTTP redirect to the captive
> > portal. In this way no DNS cache poisoning happens...
> 
> I'm not sure whether to laugh or cry.   I guess this is an improvement, at
> least... :)
>

v2.23.0 | Report a Bug | By Email