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

To: [email protected]

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

From: David Bird <[email protected]>

Date: Fri, 9 Nov 2018 07:10:25 -0800

Archived-at: <https://mailarchive.ietf.org/arch/msg/captive-portals/30LtPAOQQ2jogtezpRDjhyg2DCQ>

Authentication-results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com

Cc: [email protected]

Delivered-to: [email protected]

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HupY0v7JSlZHDDTqenbbsxXPWV086qM7aD1vjHB+XyE=; b=R5lZX6YKeb0BCIGIAVWQEfS5nbOIqn2b81xVm6Pxj3HHpDuFh9SXXiTDvd4YujtRjg wJ8LpYbp1jSUVRRR8kDdf4pswb7DD+nUgGgry9Y8If4MJeZXmqKOo1Vgt57ai6ECDcH+ GCtd9jagK3cexLKbAOMy74PpB/P14fku8+OgvT2yhWDRg3k9+2NjW+jKpgwEIhIEsvXr fuZ76CX3ZltN9QlFHrHObvtOb7gHlKe4LGuefsKORrMC0Xm43IfJsUsXnZFfsuU50Jmr UlkgWWncizG0FVMd+a5aXT91WF+Kf3vbv9LtaSFIWlap1jKTwMmdtjVa5uVBvFXq9Zry Lg3A==

In-reply-to: <CALak_b17Dw-gBn=6JzSzFhSdRdkuLL0DY9XK2BErU954RLHpag@mail.gmail.com>

List-archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>

List-help: <mailto:[email protected]?subject=help>

List-id: Discussion of issues related to captive portals <captive-portals.ietf.org>

List-post: <mailto:[email protected]>

List-subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:[email protected]?subject=subscribe>

List-unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:[email protected]?subject=unsubscribe>

References: <CALak_b17Dw-gBn=6JzSzFhSdRdkuLL0DY9XK2BErU954RLHpag@mail.gmail.com>

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 protected]> wrote:

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
_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals