Subject: [Captive-portals] Comment on Captive Portal Architecture

From: Nasir Hafeez <[email-masked]>
Date: Fri, 9 Nov 2018 13:19:30 +0700

As discussed in yesterday's IETF meeting, CAPPORT Architecture states that
the CAPPORT web server signals allow/deny rules to Captive Portal
Enforcement device. In reality, however, there may be intermediate devices
like RADIUS servers or WiFi controllers that are doing that signaling, not
the CAPPORT web server (and in the case of walled garden entries, the web
portal is never involved). The architecture diagram and related sections of
the document should perhaps be updated to show that.

Another option that occurred to me was using LLDP for capport signaling. Do
you think there is any utility in pursuing this?

Regards,

Nasir Hafeez

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 9 Nov 2018 14:09:52 +0000

LLDP may not traverse any layer-2 device (actually should not). PvD (even in an IPv4-only environment) has obviously my preference ;-)

I thought that the ‘box’ in the draft where components, where component being an app, a container or a set of containers/boxes. Rather than making the diagram complex, I would prefer to make sure that it is understood what component means

Nice and useful cancelled meeting yesterday

-éric

From: Captive-portals <[email-masked]> on behalf of Nasir Hafeez <[email-masked]>
Date: Friday, 9 November 2018 at 13:20
To: "[email-masked]" <[email-masked]>
Subject: [Captive-portals] Comment on Captive Portal Architecture

As discussed in yesterday's IETF meeting, CAPPORT Architecture states that the CAPPORT web server signals allow/deny rules to Captive Portal Enforcement device. In reality, however, there may be intermediate devices like RADIUS servers or WiFi controllers that are doing that signaling, not the CAPPORT web server (and in the case of walled garden entries, the web portal is never involved). The architecture diagram and related sections of the document should perhaps be updated to show that.

Another option that occurred to me was using LLDP for capport signaling. Do you think there is any utility in pursuing this?

Regards,

Nasir Hafeez

---

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Fri, 9 Nov 2018 14:55:03 +0000

This may be a stupid question, but do mobile operating systems even have an LLDP stack?

tim

From: Captive-portals <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <[email-masked]>
Date: Friday, November 9, 2018 at 9:10 AM
To: Nasir Hafeez <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Captive-portals] Comment on Captive Portal Architecture

-éric

Regards,

Nasir Hafeez

---

From: David Bird <[email-masked]>
Date: Fri, 9 Nov 2018 07:10:25 -0800

LLDP is interesting, but, as you mentioned, the enforcement function might
be one of several intermediate devices...

ICMP has a few benefits.. It contains entropy by quoting original packet
headers and UEs already get ICMP for a variety of network conditions (no
route, needs frag, port unavailable, administratively prohibited) -- Is
'Captive portal required' so different?

On Thu, Nov 8, 2018 at 10:20 PM Nasir Hafeez <[email-masked]>
wrote:

> Another option that occurred to me was using LLDP for capport signaling.
> Do you think there is any utility in pursuing this?
>
> Regards,
>
> Nasir Hafeez
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Nov 2018 19:15:01 -0500

Nasir Hafeez <[email-masked]> wrote:
    > Another option that occurred to me was using LLDP for capport
    > signaling. Do you think there is any utility in pursuing this?

It would be interesting for a capable captive portal to send and listen on
LLDP *as well*.

In particular, LLDP lets the captive portal get MUD signals from the new
device as well.  This is important as captive portals won't be able to
challenge many devices that might be carried by people in the future,
and it would be a nice addition if a person could authorize a
second device they happen to own via their laptop.

This is very much out of scope for current work.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-