Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

[David Bird <[e-mail]>]

Hi Kyle,

I was thinking based on Section 3, The Captive-Portal Link Relation Type,
the RFC7710 URL could be just about anything -- anything that prompts an
existing captive portal redirection where a Link Relation is sending the
API end-point to the right location...

On Thu, Mar 28, 2019 at 11:08 AM Kyle Larose <[e-mail]> wrote:
>
> David,
>
> On Wed, 27 Mar 2019 at 08:26, David Bird
> <dbird=[e-mail]> wrote:
> >
> > This is assuming that DHCP and RA will be handing out unique URLs to
UEs encoded with the necessary token identifying the UE.
> >
>
> At IETF 100 we discussed how the various components interacting with
> the captive portal would be identified.
> One of the methods was "implicit" identification -- i.e. rely on the
> source MAC, IP, etc. to identify. If the API
> end-point is located such that this is feasible, then the DHCP/RA
> won't need to encode the identity in the URL.
> That said, this does restrict where the API could be, unless the
> Enforcement Device can tunnel the request
> to the API with some form of identifying characteristic contained in
> the encapsulation's metadata, or someone
> figures out a simpler technique to securely augment the request with
> the necessary info. I'm not sure how people
> feel about that, or whether it is truly feasible.
>
> > If that is not possible, then the URL is likely to be anything outside
the walled garden so that the API end-point gets caught up in the existing
HTTP redirection to get the right UE specific URL.
>
> To clarify, you mean *not* likely, right?
>
> Overall, I don't think (correct me if I'm wrong) we're saying that the
> captive portals will immediately stop doing
> the redirection. Rather, they will likely continue to support that
> until a critical mass of UEs support the new
> mechanisms.
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals