Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
On Tue, Sep 1, 2020 at 9:49 AM David Dolson wrote: > How do such devices obtain IP addresses? > > In IPv4, this would be NAT. The first host to connect would probably pass the captive portal for all other devices, but only because of the HTTP-intercept technique. No clients would see the API URL, and they would never be able to learn the venue URL In IPv6 it's more complicated, and largely not yet addressed. With Proxy ND, the downstream clients would see the RA/DHCPv6 option(s). With 64share, the same is possible but would, I suspect, be implementation-dependent. Arguably the domain of Captive Portal solution is limited to the case when > the agent assigning IP addresses is controlling access to the network as > well. > > -Dave > As we've currently scoped things, I agree. The more I think about it, the use case I had in mind (capport implementation in an ISP's modem/CPE) would probably require things we've not yet completed. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
Warren and I had discussed whether {it would suffice for there to be /
there needs to be} an ops draft somewhere that says "if you see these
things upstream, replicate them downstream (unless you somehow know
better)".
DNS and NTP servers might be in this set. 7710bis would definitely be in
this set.
On Mon, Aug 31, 2020 at 10:43 PM Martin Thomson wrote:
> These cases, along with the very common case of a router that is
> on-premises and sits between an ISP and a local network, were discussed,
> but I don't recall ever reaching a conclusion.
>
> On Tue, Sep 1, 2020, at 15:28, Erik Kline wrote:
> > One thing I realized that we didn't discuss in 7710bis, and didn't
> > really discuss here either, is the issue of devices attached to routers
> > which are themselves on the link with the provisioning service.
> >
> > Such clients would not have a way to receive an RA option nor any of
> > the DHCP options since we didn't say what routers that observe these on
> > a network should do (e.g. routers should/may include verbatim the
> > 7710bis options in any of the applicable mechanisms for downstream
> > clients).
> >
> > The section 2.5 captive portal signal might be able to come to the
> > rescue here, but as we don't have such a thing.
> >
> > But...maybe that's a separate document?
> >
> > On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson wrote:
> > > The editors of draft-ietf-capport-architecture have put in a huge
> amount of work over the past few weeks in addressing the review comments.
> > >
> > > https://tools.ietf.org/html/draft-ietf-capport-architecture-09
> > >
> > > As there have been quite a few changes, I would like to request that
> people take a brief look again before we proceed. I've been watching
> closely, and the changes look good, but I would like to confirm. The
> changes are:
> > >
> > >
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-09.txt
> > >
> > > Please send comments before 2020-08-16.
> > >
> > > ___
> > > 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
> >
>
> ___
> 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] A final check on draft-ietf-capport-architecture-09
These cases, along with the very common case of a router that is on-premises and sits between an ISP and a local network, were discussed, but I don't recall ever reaching a conclusion. On Tue, Sep 1, 2020, at 15:28, Erik Kline wrote: > One thing I realized that we didn't discuss in 7710bis, and didn't > really discuss here either, is the issue of devices attached to routers > which are themselves on the link with the provisioning service. > > Such clients would not have a way to receive an RA option nor any of > the DHCP options since we didn't say what routers that observe these on > a network should do (e.g. routers should/may include verbatim the > 7710bis options in any of the applicable mechanisms for downstream > clients). > > The section 2.5 captive portal signal might be able to come to the > rescue here, but as we don't have such a thing. > > But...maybe that's a separate document? > > On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson wrote: > > The editors of draft-ietf-capport-architecture have put in a huge amount of > > work over the past few weeks in addressing the review comments. > > > > https://tools.ietf.org/html/draft-ietf-capport-architecture-09 > > > > As there have been quite a few changes, I would like to request that people > > take a brief look again before we proceed. I've been watching closely, and > > the changes look good, but I would like to confirm. The changes are: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-09.txt > > > > Please send comments before 2020-08-16. > > > > ___ > > 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 > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
Martin Thomson wrote: >> I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on. > Ack. Personally, I'm more concerned about implementations allowing an > override option other than through modifying the trust store. A domain > name is equally problematic there (let's hope we don't see .home > addresses...). But I don't see any easy path to a per-host override > based on what I've seen in implementations so far. Again, some enterprise PHB will point to this paragraph and tell the techie that s/he doesn't need to do things the right way. I've been there. So I would like to know why we added it. We can specify a subset of RFC6125. >> The next part says: >> An Enforcement Device SHOULD allow access to any >> services that User Equipment could need to contact to perform >> certificate validation, such as OCSP responders, CRLs, and NTP >> servers; >> >> That's a good list, and that list can be seen from looking at the >> certificates that the captive portal operator is going to use. >> But, aren't there *also* systems (Mozilla? Chrome?) where the respective >> vendors are collecting that info into a central place to make stuff go >> faster? I can't quite find what I'm looking for in a search, because >> OCSP-Stapling is not what I'm talking about, and eliminates the need. > Yes, browsers are providing systems that help with revocation. Mozilla > has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what > Microsoft and Apple might be doing differently. Those systems that I'm > aware of don't require network access at validation time. The whole > point being to provide timely information about revocation without > depending on a live OCSP or CRL fetch (which have poor privacy > properties in addition to adding to fragility). Ah, okay. The CRL is "built-in", so it does not need to be fetched while in captivity. Thank you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
On Mon, Aug 10, 2020, at 14:18, Michael Richardson wrote: > I've read through the diffs: Thanks! > This was added based upon some review comment. > While I can't really object to the idea, I am concerned. > What are the transports that result in only being able to provide a public IP > address? How many common PKI trust anchors are supporting iPAddress SANs > today? There are no methods for providing an API URL that don't support a domain name. That said, this iPAddress thing is just reiterating a requirement from RFC 6125. It isn't *widely* supported, but most clients do respect iPAddress SANs (browsers do for certain), and there are a couple of CAs that support issuance. ACME recently grew a validation mechanism for IP (RFC 8738). > I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die > on. Ack. Personally, I'm more concerned about implementations allowing an override option other than through modifying the trust store. A domain name is equally problematic there (let's hope we don't see .home addresses...). But I don't see any easy path to a per-host override based on what I've seen in implementations so far. > The next part says: > An Enforcement Device SHOULD allow access to any > services that User Equipment could need to contact to perform > certificate validation, such as OCSP responders, CRLs, and NTP > servers; > > That's a good list, and that list can be seen from looking at the > certificates that the captive portal operator is going to use. > But, aren't there *also* systems (Mozilla? Chrome?) where the respective > vendors are collecting that info into a central place to make stuff go > faster? I can't quite find what I'm looking for in a search, because > OCSP-Stapling is not what I'm talking about, and eliminates the need. Yes, browsers are providing systems that help with revocation. Mozilla has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what Microsoft and Apple might be doing differently. Those systems that I'm aware of don't require network access at validation time. The whole point being to provide timely information about revocation without depending on a live OCSP or CRL fetch (which have poor privacy properties in addition to adding to fragility). ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
I've read through the diffs: One that jumped out at me: If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the behavior described above. This was added based upon some review comment. While I can't really object to the idea, I am concerned. What are the transports that result in only being able to provide a public IP address? How many common PKI trust anchors are supporting iPAddress SANs today? This seems like it's opening a situation where someone will deploy on RFC1918 addresses and then expect clients to do some exception processing. Particularly in corporate guest networks where they only tested with their devices that already have their private PKI anchors. I can think of a few captive portal product managers that I have interacted with that would simply not understand this. I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on. The next part says: An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; That's a good list, and that list can be seen from looking at the certificates that the captive portal operator is going to use. But, aren't there *also* systems (Mozilla? Chrome?) where the respective vendors are collecting that info into a central place to make stuff go faster? I can't quite find what I'm looking for in a search, because OCSP-Stapling is not what I'm talking about, and eliminates the need. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
