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

From: Hui Deng <[email-masked]>
Date: Sun, 10 Apr 2011 12:31:41 +0800

Today's most operators are using captive portal for wifi authentication,
I would agree this problem exists widely and encourage to include it into
the PS.

thanks a lot

-Hui

2011/3/31 <[email-masked]>

>
> Any other comments with regards to this text? Is there an agreement to
> include it into the PS?
>
> > -----Message d'origine-----
> > De : [email-masked] [mailto:[email-masked]]
> > Envoyé : lundi 28 mars 2011 17:47
> > À : [email-masked]; [email-masked]
> > Cc : [email-masked]; [email-masked]
> > Objet : RE: AD review of draft-ietf-mif-current-practices
> >
> > Ted,
> >
> > Good text. I agree the problem exist. The DNS server selection points to
> > this issue as well:
> > --
> > (DISCUSS:
> >    What about those DNS servers that instead of negative answer always
> >    return positive reply with an IP address of some captive portal?)
> > --
> >
> > IMHO the problem section should say that this problem (usually/always)
> > disappears right after M1 has authenticated to the captive portal and
> > interface becomes truly "up". I.e. human intervention is required to
> clear
> > the situation, but once cleared, things work as they should - until
> > captive portal possibly wants to renew authentication..
> >
> > This problem btw means the M1 cannot start validating responses until
> > authentication with captive portal shas been completed.
> >
> > Best regards,
> >
> >       Teemu
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > > ext Ted Lemon
> > > Sent: 28. maaliskuuta 2011 17:25
> > > To: Jari Arkko
> > > Cc: [email-masked]; mif
> > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices
> > >
> > > FYI, this is a rough approximation of the text I would want to add:
> > >
> > > 4.1a.  DNS resolution issues with captive portals
> > >
> > >    A MIF node (M1) has an active interface(I1) connected to a network
> > >    (N1) which has its DNS server (S1) and another active interface
> > >    (I2) connected to a network (N2) which has its DNS server (S2).  S1
> > >    is configured to respond to any A or AAAA record query with the
> > >    IP address of a captive portal, so as to redirect web browsers to an
> > >    access control portal web page.  Any of the following situations
> > >    may occur:
> > >
> > >    1.  M1 stack, based on its routing table, uses I2 to reach S1 to
> > >        resolve "a.example.com".  M1 never reaches S1.  The name
> > >        is not resolved.
> > >    2.  M1 keeps only one set of DNS server addresses from the received
> > >        configuration objects and kept S2 address.  M1 sends the
> > >        forward DNS query for a.example.com to S2.  S2 responds with
> the
> > >        correct answer, R1.   M1 attempts to contact R1 by way of I1.
> > >        The connection fails.     Or, the connection succeeds,
> > >        bypassing the security policy on N1, possibly exposing the
> > >        owner of M1 to prosecution.
> > >    3.  M1 keeps only one set of DNS server addresses from the received
> > >        configuration objects and kept S1 address.  M1 sends the DNS
> > >        query for a.example.com to S1.  S1 provides the address of its
> > >        captive portal.   S1 attempts to contact this IP address using
> > >        I1.   The application tries to connect to the wrong destination
> > >        node, resulting in lack of service and possible security issues.
> > >    4.  M1 has resolved an FQDN to the IP address of the captive portal
> > >        connected to N1.  If the node loses connection to N1, the node
> > >        may try to connect, via N2, to the same IP address as earlier,
> > >        but as the address was only locally valid, connection setup
> > >        fails.
> > > _______________________________________________
> > > mif mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mif
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: <[email-masked]>
Date: Tue, 12 Apr 2011 10:48:40 +0200

Hi,

-11 of problem statement has succinct considerations on captive portal; but clearly it is worth to be detailed. So, based on Ted's text, the problem statement has been updated accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-12.txt   (section 4.1)

Pierrick

________________________________

De : Hui Deng [mailto:[email-masked]] 
Envoyé : dimanche 10 avril 2011 06:32
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)

I would agree this problem exists widely and encourage to include it into the PS.

thanks a lot

-Hui

Any other comments with regards to this text? Is there an agreement to include it into the PS?

> interface becomes truly "up". I.e. human intervention is required to clear
> >        resolve "a.example.com <http://a.example.com/> ".  M1 never reaches S1.  The name
> >        is not resolved.
> >        forward DNS query for a.example.com <http://a.example.com/>  to S2.  S2 responds with the
> >        query for a.example.com <http://a.example.com/>  to S1.  S1 provides the address of its

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 Apr 2011 11:01:54 -0700

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

--julien

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Apr 2011 14:31:29 -0400

On Apr 12, 2011, at 2:01 PM, Julien Laganier wrote:
> 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… :)

---

From: <[email-masked]>
Date: Wed, 13 Apr 2011 11:08:52 +0200

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.

> De : Ted Lemon [mailto:[email-masked]]
> Envoyé : mardi 12 avril 2011 20:31
> À : Julien Laganier
> Cc : Hui Deng; SEITE Pierrick RD-RESA-REN; [email-masked]
> Objet : Re: [mif] prblem statement: DNS/captive portals - was (RE: AD
> review of draft-ietf-mif-current-practices)
> 
> I'm not sure whether to laugh or cry.   I guess this is an improvement, at
> least... :)
>