Captivity enforcement

[yiannisy]

Hi,

The current documents treat captivity as a transient phase with a well-defined exit process. Often, the users stay in a "captive" mode longer, and they can still access certain resources/websites/apps. Airplanes and out-of-balance mobile users are certain examples.

It is well-known that the network has challenges to enforce desired policies, and falls back into using hacks like DNS/SNI/IP allow lists.

Is the group interested to examine the enforcement aspect, and how the client's OS can assist such enforcement so that they can still work with DoH, ECH etc? We've been looking at use cases that require some sort of "network authorization", and this might be relevant.

Thanks, Yiannis

p.s.: I tried twice to subscribe to the IETF mailing list but got no confirmation e-mail or anything. Please let me know if you prefer to move this discussion there and if you could check pending subscription in the mailing list.

[ekline]

Yannis,

Did you try these instructions to subscribe:

https://www.ietf.org/mailman/listinfo/captive-portals

If those didn't/don't work, something might be broken.

On Fri, Oct 23, 2020 at 2:10 PM Yiannis notifications@github.com wrote:

Hi,

The current documents treat captivity as a transient phase with a well-defined exit process. Often, the users stay in a "captive" mode longer, and they can still access certain resources/websites/apps. Airplanes and out-of-balance mobile users are certain examples.

It is well-known that the network has challenges to enforce desired policies, and fall backs to using hacks like DNS/SNI/IP allow lists.

Is the group interested to examine the enforcement aspect, and how the client's OS can assist such enforcement so that they can still work with DoH, ECH etc? We've been looking at use cases that require some sort of "network authorization", and this might be relevant.

Thanks, Yiannis

p.s.: I tried twice to subscribe to the IETF mailing list but got no confirmation e-mail or anything. Please let me know if you prefer to move this discussion there and if you could check pending subscription in the mailing list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/capport-wg/api/issues/37, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAERX5OR7BSI4LWDG5O55L3SMHWM5ANCNFSM4S5BIEUQ .

[yiannisy]

Hi Erik,

Yes, I did both on Friday and a few minutes ago and haven't gotten any confirmation from the list. I am already subscribed to a few IETF mailing lists and haven't had an issue before.

===================== Yiannis Yiakoumis Co-Founder & CEO https://selfienetworks.com | +1-650-644-7857

On Mon, Oct 26, 2020 at 2:02 PM, Erik Kline < notifications@github.com > wrote:

Yannis,

Did you try these instructions to subscribe:

https:/ / www. ietf. org/ mailman/ listinfo/ captive-portals ( https://www.ietf.org/mailman/listinfo/captive-portals )

If those didn't/don't work, something might be broken.

On Fri, Oct 23, 2020 at 2:10 PM Yiannis < notifications@ github. com ( notifications@github.com ) > wrote:

Hi,

The current documents treat captivity as a transient phase with a well-defined exit process. Often, the users stay in a "captive" mode longer, and they can still access certain resources/websites/apps. Airplanes and out-of-balance mobile users are certain examples.

It is well-known that the network has challenges to enforce desired policies, and fall backs to using hacks like DNS/SNI/IP allow lists.

Is the group interested to examine the enforcement aspect, and how the client's OS can assist such enforcement so that they can still work with

DoH, ECH etc? We've been looking at use cases that require some sort of "network authorization", and this might be relevant.

Thanks, Yiannis

p.s.: I tried twice to subscribe to the IETF mailing list but got no confirmation e-mail or anything. Please let me know if you prefer to move this discussion there and if you could check pending subscription in the

mailing list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https:/ / github. com/ capport-wg/ api/ issues/ 37 ( https://github.com/capport-wg/api/issues/37 ) >, or unsubscribe < https:/ / github. com/ notifications/ unsubscribe-auth/ AAERX5OR7BSI4LWDG5O55L3SMHWM5ANCNFSM4S5BIEUQ ( https://github.com/notifications/unsubscribe-auth/AAERX5OR7BSI4LWDG5O55L3SMHWM5ANCNFSM4S5BIEUQ ) > .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub ( https://github.com/capport-wg/api/issues/37#issuecomment-716821394 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAAUJVJBRZSZI4IU2GMKVDTSMXPVNANCNFSM4S5BIEUQ ).

[martinthomson]

Hmm, try mailing ietf-action at ietf.org for help.