[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach



Hoping to summarize this thread; 

- ICMP shouldn't carry and "configuration", but as notification only, it is no worse than traditional ICMP; draft update, thanks Warren.

- There is a concern in linking DHCP functions and captive portal. Perhaps, if the DHCP setting is always static (e.g. it is not used to indicate explicitly that certain devices are subject to CP and others, who might have "auto-authenticated", aren't), it becomes just configuration and not integration. 

- There are concerns that DHCP isn't the only way to obtain network configuration... a couple suggestions:

    -- In a different thread, .well-known URIs were suggested. The DHCP parameters could be IP addresses instead of URI (hmm, does the current draft really mean URL?) and the URI part is a .well-known

   -- In the absence of the DHCP parameter, the default gateway is used.

Keep in mind, this CP-IP/.well-known/cp-redirect is the "entry" point to the CP. It is expected that the application answering will have the necessary information (like client MAC address, IP address, etc) to format the CP URL that otherwise would have been in a 302 redirect. so, the CP web application can, and should, be using HTTPS.

What capport-icmp brings is a means of CP notification - a more specific replacement for traditional Dest. Unreach. or TCP Reset, or simply dropped packets. Oh, and also a whole lot better than hijacking HTTPS :)


David

See you in Yokohama! 


On Tue, May 5, 2015 at 8:46 AM, Nicolas Mailhot <[email protected]> wrote:

Le Ven 1 mai 2015 13:42, Yaron Sheffer a écrit :
> As a user, I have never seen a case where the captive portal is not on
> the same link as the client device, and never seen a case where an IP is
> obtained using a non-DHCP mechanism when in a CP setting. Can you give
> some concrete examples?

user   ]
(local ]---[ Corp Network ]
dhcp ) ]     |
             |   [ Corp Datacenter 1     ]   [ www gateway 1 ]
             |---[ with internal webapps ]---[ with captive  ]-|
             |   [ in direct access      ]   [ portal        ] |--[ W ]
             |                                                    [ W ]
             |   [ Corp Datacenter 2     ]   [ www gateway 2 ] |--[ W ]
             |---[ with internal webapps ]---[ with captive  ]-|
                 [ in direct access      ]   [ portal        ]
                          |
                 [ Permanent VPN tunnel ]
                          |
                 [ Partner datacenter   ]
                 [ and internal webapps ]
                 [ in direct access     ]

Two datacenters and www links since that's the minimum for business
continuity, can be more easily. Captive portal can and is dedicated to www
http(s) access not other firewalled protocols

If such configurations didn't exist there would be no need for pac files.

--
Nicolas Mailhot

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals