Re: [Captive-portals] Remediation url for CAPPORT
I also thought "remediation-supported" was not ideal but could not come up with a better name. "can-extend-session" does sound clearer to me. Cheers, Remi On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly wrote: > I'm fine with adding the boolean to the main draft. I discussed this a bit > with Heng yesterday, and we discussed naming it something like > "can-extend-session". Thoughts on that name? > > Thanks, > Tommy > > On Jan 16, 2020, at 11:25 PM, Remi NGUYEN VAN < > reminv=40google@dmarc.ietf.org> wrote: > > As far as the Android implementation is concerned, I think it would be > nice to have capport API support in the next (android R) version; however > due to deadlines, it's going to be harder for me to change the attributes > read from the API very soon. > Following this discussion my current plan is to support an optional > "remediation-supported" boolean, and only prompt users to extend their > session shortly before it expires when it is set to true. Hopefully the > boolean can be added to the current draft or in a future, separate draft > considering that we seem to roughly agree on it, but if the group > eventually realizes that it wants to go in another direction, we'll update > behavior in subsequent releases. > > Does that make sense ? > > Cheers, > > Remi > > On Wed, Jan 15, 2020 at 9:30 AM Erik Kline wrote: > >> If there's working group consensus to add it to the current API draft >> then definitely add it. Otherwise, probably a separate document that would >> need a call for wg adoption. >> >> Separately, and hopefully without starting a massive bikeshed, is there a >> more apt word than "remediation"? I think this specific word carries the >> connotation of "fixing an error" or "correcting damage" and it seems like >> the use here would be broader. But perhaps I'm completely mistaken. >> >> On Tue, 14 Jan 2020 at 16:21, Heng Liu wrote: >> >>> It seems most are comfortable with adding a remediation-capable boolean, >>> which is simpler than another url while also making it explicit on whether >>> remediation is provided or not, so UE could display different notifications. >>> >>> Anyone have any objections on adding this boolean please? >>> >>> If not, what's the next step on moving this forward please? >>> >>> Thanks, >>> Heng >>> >>> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly wrote: >>> >>>> Any captive portal that is newly adopting the CAPPORT API will >>>> hopefully be testing the setup in the new model, and will have to think >>>> about which URLs to map to different user experiences. >>>> >>>> A page that only says "you're logged in!", and has no way of adding >>>> more time, etc, is in my opinion a relatively useless page. If we provide a >>>> separate URL for remediation, it would seem to encourage such a design. Not >>>> including this would hopefully urge the portal design to a cleaner model. >>>> >>>> I do think the boolean is nice for highlighting to the captive portal >>>> deployer that they should think about remediation. I'd be more ok with that >>>> model, although it could also be an extension as we gain experience in >>>> deployment. >>>> >>>> Thanks, >>>> Tommy >>>> >>>> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN < >>>> reminv=40google@dmarc.ietf.org> wrote: >>>> >>>> If we show prompts to the user shortly before the session expires, we'd >>>> like to make sure that we can redirect them to some page where they can fix >>>> the problem, instead of landing on a page saying "you're logged in". The >>>> user-portal-url would work fine with a remediation-supported boolean for >>>> that purpose; having a separate URL gives additional flexibility to the >>>> access point operator, but from the point of view of the client I think >>>> both are fine. >>>> >>>> Cheers, >>>> >>>> Remi >>>> >>>> >>>> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly >>> 40apple@dmarc.ietf.org> wrote: >>>> >>>>> I have a similar initial reaction to Erik's. Adding another URL that >>>>> effectively is just another user portal, but meant to be used at certain >>>>> times, adds a lot of complexity. I'm certainly not ruling out adding such >>
Re: [Captive-portals] Remediation url for CAPPORT
As far as the Android implementation is concerned, I think it would be nice to have capport API support in the next (android R) version; however due to deadlines, it's going to be harder for me to change the attributes read from the API very soon. Following this discussion my current plan is to support an optional "remediation-supported" boolean, and only prompt users to extend their session shortly before it expires when it is set to true. Hopefully the boolean can be added to the current draft or in a future, separate draft considering that we seem to roughly agree on it, but if the group eventually realizes that it wants to go in another direction, we'll update behavior in subsequent releases. Does that make sense ? Cheers, Remi On Wed, Jan 15, 2020 at 9:30 AM Erik Kline wrote: > If there's working group consensus to add it to the current API draft then > definitely add it. Otherwise, probably a separate document that would need > a call for wg adoption. > > Separately, and hopefully without starting a massive bikeshed, is there a > more apt word than "remediation"? I think this specific word carries the > connotation of "fixing an error" or "correcting damage" and it seems like > the use here would be broader. But perhaps I'm completely mistaken. > > On Tue, 14 Jan 2020 at 16:21, Heng Liu wrote: > >> It seems most are comfortable with adding a remediation-capable boolean, >> which is simpler than another url while also making it explicit on whether >> remediation is provided or not, so UE could display different notifications. >> >> Anyone have any objections on adding this boolean please? >> >> If not, what's the next step on moving this forward please? >> >> Thanks, >> Heng >> >> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly wrote: >> >>> Any captive portal that is newly adopting the CAPPORT API will hopefully >>> be testing the setup in the new model, and will have to think about which >>> URLs to map to different user experiences. >>> >>> A page that only says "you're logged in!", and has no way of adding more >>> time, etc, is in my opinion a relatively useless page. If we provide a >>> separate URL for remediation, it would seem to encourage such a design. Not >>> including this would hopefully urge the portal design to a cleaner model. >>> >>> I do think the boolean is nice for highlighting to the captive portal >>> deployer that they should think about remediation. I'd be more ok with that >>> model, although it could also be an extension as we gain experience in >>> deployment. >>> >>> Thanks, >>> Tommy >>> >>> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN < >>> reminv=40google@dmarc.ietf.org> wrote: >>> >>> If we show prompts to the user shortly before the session expires, we'd >>> like to make sure that we can redirect them to some page where they can fix >>> the problem, instead of landing on a page saying "you're logged in". The >>> user-portal-url would work fine with a remediation-supported boolean for >>> that purpose; having a separate URL gives additional flexibility to the >>> access point operator, but from the point of view of the client I think >>> both are fine. >>> >>> Cheers, >>> >>> Remi >>> >>> >>> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly >> 40apple@dmarc.ietf.org> wrote: >>> >>>> I have a similar initial reaction to Erik's. Adding another URL that >>>> effectively is just another user portal, but meant to be used at certain >>>> times, adds a lot of complexity. I'm certainly not ruling out adding such a >>>> key as need arises, but I'd hesitate to make it part of the initial set. >>>> >>>> Particularly, if we start seeing the "venue URL" be the main landing >>>> page we redirect people to once they're logged it, it kind of makes sense >>>> to let the user portal be the status/remediation/payment page. >>>> >>>> Tommy >>>> >>>> On Jan 13, 2020, at 4:06 PM, Erik Kline wrote: >>>> >>>> >>>> >>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu >>> 40google@dmarc.ietf.org> wrote: >>>> >>>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline wrote: >>>>> >>>>>> Why should this different from the user-portal-url? It seems to me >>>>>> that either the user-portal-url would remediation UI eleme
Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis
I think we can either try to solve this problem by having the client send an identifier to the API, or state that the API needs to be hosted inside the network. If we go with option 2, I'm afraid many vendors may just rely on DHCPv4 or Link-Relation redirects to give different URLs based on the client, which would hurt IPv6 adoption. So I'm wondering if option 1 (for example having the client send an identifier in the host header of the API request) might be strategically better. Cheers, Remi On Wed, Jul 31, 2019 at 12:56 PM Martin Thomson wrote: > If DHCP is used, then it is possible to customize the API URL to include > per-device information. In that case, the API could be remote. > > However, an IPv6 RA has to contain information that is the same for every > device in the network. > > On Wed, Jul 31, 2019, at 13:44, Chris Spencer wrote: > > Please forgive, I'm new to this group and trying to come up to speed. > > > > Would not a feed of option 82 rather than create a new API work? option > > 82 can carry MAC/IP (it could create a GUID/UUID) and other location > > identifiers? if the external portal could get a feed of this, the > > portal at layer 3 could look up the device MAC from the option 82 > > elements by the IP? or if the DHCP server is centralised along with the > > portal architecture and DHCP relay is used on the local site? > > > > - > > DHCP Option 82 Overview > > If DHCP option 82 is enabled on a VLAN or bridge domain, then when a > > network device—a DHCP client—that is connected to the VLAN or bridge > > domain on an untrusted interface sends a DHCP request, the switching > > device inserts information about the client's network location into the > > packet header of that request." > > > > > > On Wed, 31 Jul 2019 at 04:24, Martin Thomson wrote: > > > This is one of the costs of this architecture. If the external system > (portal HTML, etc...) needs access to identifiers, then the API endpoint > will have to decorate the URLs it provides. That might mean having the API > endpoint inside the network, where it can see source IP or BSSID or > whatever is being used for identification. > > > > > > An external service won't be able to validate any identifier it > receives in this way, so you might want to make the decoration a little > more complex than a simple addition of `?ip=192.0.2.3`. Of course, the > worst I can think of (offhand) is that someone could pay for my network > access. > > > > > > On Mon, Jul 29, 2019, at 13:51, Remi NGUYEN VAN wrote: > > > > So to summarize, we've got a problem where the WLAN controller has > some > > > > rules to know who is blocked / allowed (probably based on mac > address > > > > ?), and can advertise a single API URL through DHCP / RAs / > > > > Link-Relation and generate redirects, but does not have > capabilities to > > > > serve login pages or the API: this is handled by another box > upstream > > > > which has more capabilities like handling payment pages etc, and > holds > > > > the SSL certs. Because the API uses HTTPS (contrary to lots of > login > > > > pages), the WLAN controller can't easily insert identity of the > > > > requestor in the request and the API has no way to know who it's > > > > replying to. > > > > > > > > Since we can't advertise different addresses for different clients > in > > > > RAs, how about having the client add a session identifier in their > API > > > > requests ? Having the client add a mac address in an HTTP request > > > > header field would be a solution. Many devices are using random > > > > per-SSID mac addresses now, so this sounds like a reasonable > identifier > > > > for the device to give to the API server (which could get it anyway > > > > through some complicated setup).. It would be possible for clients > to > > > > make requests for API data of other clients (assuming they know > their > > > > mac address), but that's already possible by spoofing the address > > > > anyway. > > > > > > > > Cheers, > > > > > > > > Remi > > > > > > > > > > > > On Sat, Jul 27, 2019 at 8:04 AM Michael Richardson > > > > mailto:mcr%2bi...@sandelman.ca> mcr%2bi...@sandelman.ca <mailto:mcr%252bi...@sandelman.ca>>> wrote: > > > > > > > > > > Lorenzo Colitti wrote: > > > > > > Is there a problem with saying that the portal server sh
