On Fri, Oct 10, 2014 at 5:05 PM, Dale W. Carder <[email protected]> wrote: > I have a few questions / comments: > > - IPv6 has DHCP also. Can that be used instead of RA? (I am not looking > to start a war, I just want to understand why you picked RA).
I didn't - I picked DHCPv4 and DHCPv6, and a bunch of v6 folk shouted at me for doing it wrong, so I added RA and dropped DHCPv6. This made some other folk mad, so I tried both, and provided some arbitrary sorting rules. This resulted in both sides being unhappy, so I went with the tactic of keeping the scarier group (Lorenzo and Erik) happy. I have the DHCPv6 text kicking around in an SVN somewhere, happy to put that back if that is what people want... > This > might be an issue because typically RA's would be sent from routers that > are not necessarily the captive portal. A dhcp option could be more > selectively/dynamically given to clients and could support both captive > portal and non-captive portal users on the same L3 segment. Another > example use case of this would be for things pre-registered with the > portal, no need to worry them futher. > > - Should it be pointed out that this would only happen after 802.11u, > 802.11X, or similar L2 things have already failed to auth? Well, it *could* happen after -- I've seen some networks that make you *first* join a WPA network, and then still pop up a captive portal (the WPA is to keep folk off the network, and the CP it to make them agree not to do anything naughty with it). But, I think it might be worth mentioning *something* about some networks that have a "secured" network (no CP) and a "guest" network (with a CP) -- do you happen to have any suggested text? > > - You note that you want embedded address literals because the user may > have broken DNS settings for that network. Nope, I guess that this text was not clear -- if the captive portal allows DNS access (either with it's DNS servers, or using other DNS servers (like 8.8.8.8), people can (and will) use DNS tunneling (http://dnstunnel.de/) to bypass the CP. Especially if DPRIVE takes off, captive portals will have a hard time filtering these... I'll try clean this up to be clearer... > If the dhcp server gave you > dns settings which you knowingly ignored, then it is a mis-configuration. Or you simply don't trust the CP to not lie or spy on your DNS or .... > The same thing would happen if you statically configured a default > router while ignoring what was recieved in RA or DHCP. In other words > on captive portal networks, I think a more robust interpretation would > be that the DNS server supplied from the network is not a hint, it is > mandatory at least until registration. > > - What happens in the following dual-stack scenario: > dhcpv4 captive-portal option not set > dhcpv6 or RA captive-portal option set > > Does that mean the client only has to do portal registration for v4? Yes! No! I don't know! I *think* that machines should only need to do a single captive portal interaction for *all* protocols -- AFAIK, most captive portals actually base their rules on MAC address. > I > think you can guess at all the permutations when dual-stacked. It gets > worse for RA because some RA's could have it set but not others. Do we > say that this is a misconfiguration? Or do we say if the option is set > via *any* means, then assume it is set for them all? I *think* so. But, I'm happy to: A: hear other options and B: even happier to accept text. > > - What about the bad guy who sets up a rougue dhcp server with the > option set in order to extract usernames/passwords/money? I believe that if a bad guy can setup a rogue DHCP server he has already won -- he can just as easily send DHCP responses with himself as a default gateway, and then intercept, pop up a captive portal page, etc... > There was a > similar topic that came up (in sunset4, I think) about a hypothetical > dhcp option to hint to clients not to use their v4 stack. The most > robust thing for a client to do would be to ignore that option due to > the possibility of bad guys. That may also mean the most robust thing > for a client to do is treat the captive-portal option only as a hint and > not necessarily hold everything up because of it. I think that it is safer to hold everything up -- if the DHCP response *is* forged and contains a "bad" CP option it probably also contained a bad gateway, dns server, etc. In that case, holding everything up and running away is best, allowing the connection to the CP is probably second best the user *might* notice that the attacker misspelt Starbooks, and the worst is to shuffle traffic through the (supplied) gateway... Anyway, thank you very much for your feedback and review, more than happy to chat more about this, etc. W > > Dale > > Thus spake Warren Kumari ([email protected]) on Wed, Oct 01, 2014 at > 05:21:07PM -0400: >> <no hats> >> Hi there all, >> >> I have a draft that I'd like some review / feedback on. >> It will likely be AD sponsored (it doesn't really fit in any working groups). >> >> It is designed to help make the captive portal experience better^W less bad. >> We've all experienced this -- you arrive at a hotel or coffee-shop. >> You open your laptop and connect to the Hilton_Guest network (or >> whatever) and then nothing happens... >> You click refresh on your (in this day and age) https:// pages, and >> either they just hang, or you get some unintelligible SSL error about >> the certificate not matching the site you were trying to get to... or >> you have a VPN / proxy, in which case *nothing* happens. >> You kill the VPN, still nothing. >> You curse a few times, then notice that DNS isn't working. After some >> futzing (and more swearing) you disable your local validating >> resolver, and update resolv.conf to use the hotel network. >> >> Eventually you get a web page that tells you you can get to the >> Internet for the low low price of $9.95 for 24hours. 3 hours later the >> process repeats. After throwing your laptop on the floor and jumping >> up and down you redo the captive portal dance and continue using the >> 'net. >> >> Now, obviously the bestest possible outcome would be if there were no >> captive portals, but, well, that ain't going to happen.... so, this >> document lets DHCP / RA *tell* your machine where the CP is, so your >> OS can make a connection as soon as you try access the Internet. Yup, >> there are many more details, go read the draft... >> >> >> http://tools.ietf.org/html/draft-wkumari-dhc-capport-05 >> >> W >> >> >> >> >> This technique is complementary with the Wi-Fi Alliance: Hotspot 2.0 / >> PassPoint "ASRA" - Additional Steps Required for Access idea... >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
