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

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:denghui02@gmail.com] 
Envoyé : dimanche 10 avril 2011 06:32
À : SEITE Pierrick RD-RESA-REN
Cc : teemu.savolainen@nokia.com; Ted.Lemon@nominum.com; jari.arkko@piuha.net; mif@ietf.org
Objet : Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)

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 <pierrick.seite@orange-ftgroup.com>

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

> -----Message d'origine-----
> De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]
> Envoyé : lundi 28 mars 2011 17:47
> À : Ted.Lemon@nominum.com; jari.arkko@piuha.net
> Cc : draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org
> 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: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> > ext Ted Lemon
> > Sent: 28. maaliskuuta 2011 17:25
> > To: Jari Arkko
> > Cc: draft-ietf-mif-current-practices@tools.ietf.org; 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 <http://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 <http://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 <http://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
> > mif@ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif