Re: [Captive-portals] Discovering captive portal API URL via DNS?
Tommy Pauly wrote: > I wanted to clarify the issue a bit before diving into the > mitigations. Do these captive portal operators have *no* relationship > to the DHCP configuration? Presumably, the captive portal enforcement I think that the issue is that the relationship is adversarial: different silos. The example that was given previously was that DHCP belonged to the "desktop" group, while DNS belongs to the "network" group in some enterprise. The DHCP all backends (via relays) to some DHCP servers, while the DNS is operated by the "Internet" group. That probably means that capport.arpa (and ipv4.arpa) will get populated, and all of the non-captive desktops will see that. I think that this is okay. > Since the mitigation below is specific to modifying the DNS, I assume > that we are talking about captive portal solutions that work, in part, > by intercepting DNS. I don't think that is necessarily the case. The Internet group probably controls the routers, just not the DHCP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
> On Sep 3, 2019, at 4:44 PM, Lorenzo Colitti > wrote: > > All, > > During discussions with captive portal operators about implementing the > capport API, one of the stumbling blocks that keeps coming up is that the > captive portal operator does not always control the DHCP configuration and > thus cannot easily use RFC7710. Thanks for bringing this up. I wanted to clarify the issue a bit before diving into the mitigations. Do these captive portal operators have *no* relationship to the DHCP configuration? Presumably, the captive portal enforcement is done somewhere on path, in the router, or between the router and the Internet connection. And, if there is redirection of DNS going on, presumably, this is a DNS server that the captive portal (or the operator of the network) has some control over, and is provisioned via DHCP. For such portals, I would assume that it would be as easy to add a DHCP CAPPORT option as it would be to add the DNS server address of the captive portal's resolver (assuming the DHCP implementation supports the option). Since the mitigation below is specific to modifying the DNS, I assume that we are talking about captive portal solutions that work, in part, by intercepting DNS. Thanks, Tommy > > The WG has previously rejected the option of using a well-known DNS name to > discover the URL, because the API itself requires TLS, and without a hostname > it is not possible (or at least not easy) to validate the server. However, > what if the client did a CNAME query for capport.arpa (or equivalent other > local-only, non-DNSSEC-signed name), got back a CNAME for the real server, > and then assumed that the API server was https:///capport-api ? > > Alternatively, Erik and Warren suggest RFC 7553. In this scheme the client > would do a URI lookup for "capport.arpa" or equivalent, and would take the > result of that URL as the API endpoint. > > Thoughts? > > Regards, > Lorenzo > ___ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
In general, I think that the code on a client system that is intentionally interacting with a Captive Portal (for discovery, etc), will need to use the locally-provisioned DNS. That is probably Do53, but could be DoT/DoH in the future; it would, however, be expected to be under the control of the portal if there is a portal present. Even if a system is strictly using DoT/DoH for other use cases, it needs to have some local exceptions for this kind of "system" traffic. A good example is the ipv4only.arpa lookup on DNS64 networks. —Tommy > On Sep 4, 2019, at 7:16 AM, Michael Richardson wrote: > > > Lorenzo Colitti wrote: >mcr> that things like DoT/DoH can not be used by the captive portal >mcr> client. (I just want to make the assumption explicit. I'm not >mcr> complaining about it) > >> That's not really an assumption - the fact that the captive portal >> client can't do DoT/DoH is mostly true today, because unless the portal >> is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH >> clients probably already know not to attempt them on captive portals. > > Well, a captive portal could leave HTTPS to cloudflare open, the same way > that they might leave Do53 open to themselves, or to quadX. That works today > for some portals. > > And if the portal doesn't let just *any* Do53, but only to known public > resolvers (which they can even proxy if they want), then they can be sure to > defeat DNS-VPN mechanisms. > > Some portals today *do* depend upon creating answers for names that aren't > real. That fails today if you do DNSSEC validation. Of course, some still > depend upon lying about all DNS requests, and but we have agreed that this is > bad. > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works| network architect > [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
Lorenzo Colitti wrote: mcr> that things like DoT/DoH can not be used by the captive portal mcr> client. (I just want to make the assumption explicit. I'm not mcr> complaining about it) > That's not really an assumption - the fact that the captive portal > client can't do DoT/DoH is mostly true today, because unless the portal > is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH > clients probably already know not to attempt them on captive portals. Well, a captive portal could leave HTTPS to cloudflare open, the same way that they might leave Do53 open to themselves, or to quadX. That works today for some portals. And if the portal doesn't let just *any* Do53, but only to known public resolvers (which they can even proxy if they want), then they can be sure to defeat DNS-VPN mechanisms. Some portals today *do* depend upon creating answers for names that aren't real. That fails today if you do DNSSEC validation. Of course, some still depend upon lying about all DNS requests, and but we have agreed that this is bad. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
Lorenzo Colitti wrote: > During discussions with captive portal operators about implementing the > capport API, one of the stumbling blocks that keeps coming up is that > the captive portal operator does not always control the DHCP > configuration and thus cannot easily use RFC7710. Agreed. > The WG has previously rejected the option of using a well-known DNS > name to discover the URL, because the API itself requires TLS, and > without a hostname it is not possible (or at least not easy) to > validate the server. However, what if the client did a CNAME query for > capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), > got back a CNAME for the real server, and then assumed that the API > server was https:///capport-api ? > Alternatively, Erik and Warren suggest RFC 7553. In this scheme the > client would do a URI lookup for "capport.arpa" or equivalent, and > would take the result of that URL as the API endpoint. RFC7553 seems like a better choice than a CNAME hack. So we are trading the assumption that captive portal operator can control DHCP to one where captive portal operator can control/influence DNS, and that things like DoT/DoH can not be used by the captive portal client. (I just want to make the assumption explicit. I'm not complaining about it) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
