IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Tue, 12 April 2011 18:31 UTC

Return-Path: <Ted.Lemon@nominum.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 190B4E07E4 for <mif@ietfc.amsl.com>; Tue, 12 Apr 2011 11:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ADexQK744iVB for <mif@ietfc.amsl.com>; Tue, 12 Apr 2011 11:31:34 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfc.amsl.com (Postfix) with ESMTP id 8FE51E065C for <mif@ietf.org>; Tue, 12 Apr 2011 11:31:34 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTaSaheTWrMhIbSiv07jIshMRmYOY+tkw@postini.com; Tue, 12 Apr 2011 11:31:34 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9449EF8074 for <mif@ietf.org>; Tue, 12 Apr 2011 11:31:33 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8B91319005D; Tue, 12 Apr 2011 11:31:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Apr 2011 11:31:33 -0700
MIME-Version: 1.0 (Apple Message framework v1213)
Content-Type: text/plain; charset="windows-1252"
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <BANLkTincH80ye2Wm6heeJa8zDZXC7Yhraw@mail.gmail.com>
Date: Tue, 12 Apr 2011 14:31:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com>
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>
To: Julien Laganier <julien.ietf@gmail.com>
X-Mailer: Apple Mail (2.1213)
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: Tue, 12 Apr 2011 18:31:39 -0000

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