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

[Julien Laganier <[e-mail]>]

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

On Sat, Apr 9, 2011 at 9:31 PM, Hui Deng <[e-mail]> wrote:
> 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 <[e-mail]>
>>
>> Any other comments with regards to this text? Is there an agreement to
>> include it into the PS?
>>
>> > -----Message d'origine-----
>> > De : [e-mail] [mailto:[e-mail]]
>> > Envoyé : lundi 28 mars 2011 17:47
>> > À : [e-mail]; [e-mail]
>> > Cc : [e-mail]; [e-mail]
>> > 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> > > ext Ted Lemon
>> > > Sent: 28. maaliskuuta 2011 17:25
>> > > To: Jari Arkko
>> > > Cc: [e-mail]; 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/mif
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
>
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>
>