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

From: "Martin Thomson" <[email-masked]>
Date: Wed, 27 Mar 2019 08:00:39 -0400

Erik and Warren have helpfully provided this draft that updates RFC 7710.  Today we discussed this and there seemed to be general agreement to adopt.  

Please respond to this email before 2019-04-12 stating whether you think we should adopt or not.  If not, please share your reasons when you say this.

I'll be assessing consensus on this document, because my co-chair is an author.

---

From: David Bird <[email-masked]>
Date: Wed, 27 Mar 2019 05:25:50 -0700

In section 2, it states:

   for the
   foreseeable future, captive portals will still need to implement the
   interception techniques to serve legacy clients

This is assuming that DHCP and RA will be handing out unique URLs to
UEs encoded with the necessary token identifying the UE.

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.

On Wed, Mar 27, 2019 at 5:01 AM Martin Thomson <[email-masked]> wrote:

> Erik and Warren have helpfully provided this draft that updates RFC 7710.
> Today we discussed this and there seemed to be general agreement to adopt.
>
> Please respond to this email before 2019-04-12 stating whether you think
> we should adopt or not.  If not, please share your reasons when you say
> this.
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Kyle Larose <[email-masked]>
Date: Thu, 28 Mar 2019 14:00:13 -0400

We need to update the document to align with our proposed API, as well
as to address a few shortcomings I believe we have discovered since it
was first published.

I support adoption.

---

From: Kyle Larose <[email-masked]>
Date: Thu, 28 Mar 2019 14:08:14 -0400

David,

On Wed, 27 Mar 2019 at 08:26, David Bird
<dbird=[email-masked]> 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.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 28 Mar 2019 23:31:43 +0100

Agreed, this document is definitely an improvement and core to moving ahead the other working group items. I also support adoption!

Best,
Tommy

> On Mar 28, 2019, at 7:00 PM, Kyle Larose <[email-masked]> wrote:
>

---

From: David Bird <[email-masked]>
Date: Thu, 28 Mar 2019 16:01:07 -0700

Agreed, it is an improvement and a way forward..

On Thu, Mar 28, 2019 at 3:32 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Agreed, this document is definitely an improvement and core to moving
> ahead the other working group items. I also support adoption!
>
> Best,
> Tommy
>
> >> Erik and Warren have helpfully provided this draft that updates RFC
> 7710.  Today we discussed this and there seemed to be general agreement to
> adopt.
> >>
> >> Please respond to this email before 2019-04-12 stating whether you
> think we should adopt or not.  If not, please share your reasons when you
> say this.
> >>

---

From: David Bird <[email-masked]>
Date: Thu, 28 Mar 2019 16:25:03 -0700

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...

> > 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.