Subject: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 22 Jul 2019 11:17:05 -0400

I see no major issues and think this draft is ready to advance. A few nits
follow:

1. I think it would be good if the document said that the the API URL
SHOULD be the same for all clients, and that any per-client behaviour
should instead be implemented by making the content of the URL dynamically
generated, if necessary. In the same spirit, this text probably needs an
upper-case SHOULD:

====
   The captive portal operator should ensure that the
   URIs handed out are equivalent to reduce the chance of operational
   problems.  The maximum length of the URI that can be carried in IPv4
   DHCP is 255 bytes, so URIs longer than 255 bytes should not be used
   in IPv6 DHCP or IPv6 RA.
=====

2. I'm surprised that the following text is present. It seems like we
should disallow IP literals for compatibility with IPv6. But perhaps SHOULD
is enough here.

   The URI SHOULD NOT contain an IP address literal.  The URI parameter
   is not null terminated.

3. The section that documents the link relation type should mention what
should happen if the portal is already open. Should the captive portal add
this header to probe responses even if the portal is already open? if it
does not, there is no way for a device to learn the API URL if it connects
to a portal, logs in, disconnects, and then reconnects, because when it
reconnects the portal will be open.

4. In section 4, is it even worth specifying the precedence order? What if
we replaced the entirety of section 4 with:

   A device may learn about Captive Portal API URIs through more than
   one of (or indeed all of) the above options.  It is a network
   configuration error if the learned URIs are not all identical.

   If the URIs learned are not identical, clients MAY use one of more of the
   URIs without distinction.

That would IMO decrease the chances of such a configuration error being
made. :-)

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 22 Jul 2019 16:48:57 -0400

Thanks for the review Lorenzo.

On Mon, Jul 22, 2019, at 11:17, Lorenzo Colitti wrote:
> should disallow IP literals for compatibility with IPv6. But perhaps 
> SHOULD is enough here.
> 
>  The URI SHOULD NOT contain an IP address literal. 

I tend to think that the core goal is that the URI contain a target identity that can be authenticated when accessed over HTTPS.

That generally means that IP literals aren't a good idea, but I wouldn't make this statement.  I would instead emphasize that this is an HTTPS URI.  Though I would not go into great detail on what that means, I would refer to RFC 7230.

> 3. The section that documents the link relation type should mention 
> what should happen if the portal is already open. Should the captive 
> portal add this header to probe responses even if the portal is already 
> open? if it does not, there is no way for a device to learn the API URL 
> if it connects to a portal, logs in, disconnects, and then reconnects, 
> because when it reconnects the portal will be open.

Good point.  I would be interested in hearing what the working group thinks of this.

To my understanding, this is a problem that exists today.  So we may decide not to worry about this particular problem, but just document it.  That would make this path less good than other options (like DHCP/RA), but I don't want to encourage networks to intercept EVERY request that passes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 22 Jul 2019 17:43:26 -0400

On Mon, Jul 22, 2019 at 4:49 PM Martin Thomson <[email-masked]> wrote:

> I tend to think that the core goal is that the URI contain a target
> identity that can be authenticated when accessed over HTTPS.
>
> That generally means that IP literals aren't a good idea, but I wouldn't
> make this statement.  I would instead emphasize that this is an HTTPS URI.
> Though I would not go into great detail on what that means, I would refer
> to RFC 7230.
>

It's possible to use HTTPS to IP literals. But IP literals are
address-family specific. That makes it impossible to support this option in
a dual-stack network because the two URLs will be different.

> To my understanding, this is a problem that exists today.  So we may
> decide not to worry about this particular problem, but just document it.
> That would make this path less good than other options (like DHCP/RA), but
> I don't want to encourage networks to intercept EVERY request that passes.
>

Right, for networks without the capport API (i.e., all networks today) this
works. But for a network with the capport API, I think it's a problem if
the device cannot find the API URL just because the portal is open. The
reason I mention it is: this document says that the URL in the option is in
fact the API URL, and the link rel mechanism doesn't work well for the API
URL.

One option would just be to drop this mechanism. If it is clear that the
DHCP / RA solutions are feasible in real networks, I don't see much of a
need for the link rel version at all.

---

From: David Bird <[email-masked]>
Date: Mon, 22 Jul 2019 15:12:00 -0700

Are we assuming that the URL contained in the DHCP/RA is the final "session
specific" URL for which the portal is able to uniquely identify the
UE/session ?

On Mon, Jul 22, 2019 at 2:43 PM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

> Right, for networks without the capport API (i.e., all networks today)
> this works. But for a network with the capport API, I think it's a problem
> if the device cannot find the API URL just because the portal is open. The
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 22 Jul 2019 18:54:16 -0400

On Mon, Jul 22, 2019, at 17:43, Lorenzo Colitti wrote:
> address-family specific. That makes it impossible to support this 
> option in a dual-stack network because the two URLs will be different.

Just relaying a comment from someone who knows more about this than I: it would be reasonable to regard the v4 and v6 access as different "networks".  You can see how that might work when you consider that the configuration for v4 and v6 are different and could provide different answers.  I don't know how that fits with the logical model proposed in PvD though...

> One option would just be to drop this mechanism. If it is clear that 
> the DHCP / RA solutions are feasible in real networks, I don't see much 
> of a need for the link rel version at all.

Maybe this is something we could ask the WBA folks.  One nice property of that is that it fits into the 3xx interception nicely, but we're speculating here about whether this added simplicity would be useful.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 22 Jul 2019 19:25:26 -0400

No, I'm assuming that the URL in the RA is identical for all users and that
if any per-user behaviour is needed, then the content of that URL will be
dynamically generated.

On Mon, Jul 22, 2019, 18:12 David Bird <dbird=[email-masked]>
wrote:

> Are we assuming that the URL contained in the DHCP/RA is the final
> "session specific" URL for which the portal is able to uniquely identify
> the UE/session ?
>
> [email-masked] <[email-masked]>> wrote:
>

---

From: David Bird <[email-masked]>
Date: Mon, 22 Jul 2019 16:40:23 -0700

I think that assumption is problematic... the nature of captive portal
means the portal will be taking some action (e.g. releasing the UE from
captivity) specific to the UE/session, regardless of the content generated
for the URL. Captive portal networks work differently in uniquely
identifying the UE/session, but ultimately a "session-id" is typically
carried in the redirect URL on a per UE/session basis. If everyone gets the
exact same URL, this can only be done by IP address at the portal... Is
that the design networks are encouraged to take?

On Mon, Jul 22, 2019 at 4:25 PM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

> No, I'm assuming that the URL in the RA is identical for all users and
> that if any per-user behaviour is needed, then the content of that URL will
> be dynamically generated.
>
> On Mon, Jul 22, 2019, 18:12 David Bird <dbird=[email-masked]
> <[email-masked]>> wrote:
>
>>>> That generally means that IP literals aren't a good idea, but I
>>>> wouldn't make this statement.  I would instead emphasize that this is an
>>>> HTTPS URI.  Though I would not go into great detail on what that means, I
>>>> would refer to RFC 7230.
>>>>
>>>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Jul 2019 07:31:09 -0400

Hi David,

On Mon, Jul 22, 2019, at 19:40, David Bird wrote:
> ultimately a "session-id" is 
> typically carried in the redirect URL on a per UE/session basis. If 
> everyone gets the exact same URL, this can only be done by IP address 
> at the portal... Is that the design networks are encouraged to take? 

I'm not following your "this" here.  Can you say more?

I understand that a session ID is needed, but is this something that can be inserted on the transition from the API endpoint to the web page?

---

From: David Bird <[email-masked]>
Date: Thu, 25 Jul 2019 05:56:24 -0700

Hi Martin,

The "this" refers to uniquely identifying the UE/session. The API server
will need to "lookup" the UE/session in some way (like in a database shared
with AAA) to get its state (captive or not, how much time/data remaining,
etc). In this regard, the API and the Captive Portal itself *both* need
this ability to uniquely identify the UE/session.

Sure, one *could* design an API server, to reside on the same L2 segment as
the subscribers, so that it can determine the UE mac address from looking
up the remote IP address in the local ARP table. But... in practice, I
think the tendency would be to host the API in the same centralized place
as the captive portal itself (and share the same database).

In terms of generating a "session-id" ... a lot of this is very
implementation dependent. For example, many hotspot systems are integrated
with DHCP/RA because the IP address of subscribers may come from AAA (or a
PGW in 3gpp). The redirection URL is often "minted" with the right
session_id for that session by the backend AAA/PCRF.

Here is one example:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/configuration-guide/b_cg75/b_cg75_chapter_01011101.pdf

On Thu, Jul 25, 2019 at 4:31 AM Martin Thomson <[email-masked]> wrote:

> I understand that a session ID is needed, but is this something that can
> be inserted on the transition from the API endpoint to the web page?
>

---

From: David Bird <[email-masked]>
Date: Thu, 25 Jul 2019 07:09:50 -0700

Expanding on that Cisco example for a minute....

How would Cisco implement 7710bis and API?

It would make sense for Cisco to implement the API server directly into
their WLAN controller... In that case, it probably could use the same URL
for the API server for all subscribers (and be in a position to uniquely
identify the session and lookup internally its state).  [As I've argued
before, the NAS/WLC is the *right* place for capport notification - or API
- mechanism because it is the ultimate source of truth for the state of the
session -- it is, after all, the one doing the enforcement].

However,  who would own the API SSL cert? Often times, the "hotspot
services company" isn't the owner of the WLAN Controller. Ideally, the
venue is buying their own certs and installing them in their own gear..
but, is that what will happen in practice? I could also imagine that
hotspot services companies will see the API an extension of their service
and want to control it... so, my question is, how will vendors implement
this?

On Thu, Jul 25, 2019 at 5:56 AM David Bird <[email-masked]> wrote:

> Sure, one *could* design an API server, to reside on the same L2 segment
> as the subscribers, so that it can determine the UE mac address from
> looking up the remote IP address in the local ARP table. But... in
> practice, I think the tendency would be to host the API in the same
> centralized place as the captive portal itself (and share the same
> database).
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Jul 2019 12:03:03 -0400

Thanks for the extra info David,

On Thu, Jul 25, 2019, at 10:10, David Bird wrote:
> hotspot services companies will see the API an extension of their 
> service and want to control it... so, my question is, how will vendors 
> implement this? 

One possibility is to have the device phone home for a globally unique name, and maybe even a certificate (or it could implement an ACME client on its own).  It's a trick that some small devices already use.

I appreciate that this is not a trivial operation, but nor is it massively complex.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Jul 2019 14:43:54 -0400

Is there a problem with saying that the portal server should identify the
device by IP address?

On Mon, Jul 22, 2019 at 7:40 PM David Bird <dbird=
[email-masked]> wrote:

>> On Mon, Jul 22, 2019, 18:12 David Bird <dbird=
>>>> the DHCP / RA solutions are feasible in real networks, I don't see much of
>>>> a need for the link rel version at all.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 26 Jul 2019 10:01:09 -0400

To that end, any enforcement of other traffic (such as normal web page loading) will not be carrying any session identifier, so only signals that are already present in the packets, such as the IP address, are effectively useful here.

Thanks,
Tommy

> On Jul 25, 2019, at 2:43 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> Is there a problem with saying that the portal server should identify the device by IP address?
> 
> On Mon, Jul 22, 2019 at 7:40 PM David Bird <dbird=[email-masked] <mailto:[email-masked]>> wrote:
> I think that assumption is problematic... the nature of captive portal means the portal will be taking some action (e.g. releasing the UE from captivity) specific to the UE/session, regardless of the content generated for the URL. Captive portal networks work differently in uniquely identifying the UE/session, but ultimately a "session-id" is typically carried in the redirect URL on a per UE/session basis. If everyone gets the exact same URL, this can only be done by IP address at the portal... Is that the design networks are encouraged to take? 
> 
> On Mon, Jul 22, 2019 at 4:25 PM Lorenzo Colitti <lorenzo=[email-masked] <mailto:[email-masked]>> wrote:
> No, I'm assuming that the URL in the RA is identical for all users and that if any per-user behaviour is needed, then the content of that URL will be dynamically generated.
> 
> On Mon, Jul 22, 2019, 18:12 David Bird <dbird=[email-masked] <mailto:[email-masked]>> wrote:
> Are we assuming that the URL contained in the DHCP/RA is the final "session specific" URL for which the portal is able to uniquely identify the UE/session ?
> 
> On Mon, Jul 22, 2019 at 2:43 PM Lorenzo Colitti <lorenzo=[email-masked] <mailto:[email-masked]>> wrote:
> On Mon, Jul 22, 2019 at 4:49 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> It's possible to use HTTPS to IP literals. But IP literals are address-family specific. That makes it impossible to support this option in a dual-stack network because the two URLs will be different.
> 
> Right, for networks without the capport API (i.e., all networks today) this works. But for a network with the capport API, I think it's a problem if the device cannot find the API URL just because the portal is open. The reason I mention it is: this document says that the URL in the option is in fact the API URL, and the link rel mechanism doesn't work well for the API URL.
> 
> One option would just be to drop this mechanism. If it is clear that the DHCP / RA solutions are feasible in real networks, I don't see much of a need for the link rel version at all.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2019 19:03:47 -0400

Tommy Pauly <tpauly=[email-masked]> wrote:
    > To that end, any enforcement of other traffic (such as normal web page
    > loading) will not be carrying any session identifier, so only signals
    > that are already present in the packets, such as the IP address, are
    > effectively useful here.

It's not obvious to me that you are talking about the same thing!
The portal server *could* use IP address as the key by which to identify
the device to the Captive Portal Enforcer.

That requires that the access to the Captive Portal Server to always
be on the same side of a NAT44 as the client, and I don't think that is
realistic given how these services are outsourced.

(In architecture-04, we have "Captive Portal Enforcement", which seems
to be an activity, while the description is about a thing.  So I think
that either the word "Point" should be added, or Enforcement->Enforcer)

The Captive Portal Enforcer SHOULD enable traffic based upon the mapped
L2 address, otherwise, there would have to be a new portal session for
IPv4 and IPv6, and for each new IPv6 temporary/privacy address.
I don't think we want that.  It would also, I think, force the portal
server to speak both v4 and v6.

The communication between Captive Portal Server and Captive Portal Enforcer
COULD identify the client by L3 address, but I wouldn't want to build things
that way, because it would result in a poor experience for returning users,
such as sleepy phones, or hotel guests that might leave the hotel and then
return later in the day, and expect their 24hr pass to just work, despite
DHCP leases being much shorter.

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

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Mon, 29 Jul 2019 12:51:08 +0900

So to summarize, we've got a problem where the WLAN controller has some
rules to know who is blocked / allowed (probably based on mac address ?),
and can advertise a single API URL through DHCP / RAs / Link-Relation and
generate redirects, but does not have capabilities to serve login pages or
the API: this is handled by another box upstream which has more
capabilities like handling payment pages etc, and holds the SSL certs.
Because the API uses HTTPS (contrary to lots of login pages), the WLAN
controller can't easily insert identity of the requestor in the request and
the API has no way to know who it's replying to.

Since we can't advertise different addresses for different clients in RAs,
how about having the client add a session identifier in their API requests
? Having the client add a mac address in an HTTP request header field would
be a solution. Many devices are using random per-SSID mac addresses now, so
this sounds like a reasonable identifier for the device to give to the API
server (which could get it anyway through some complicated setup). It would
be possible for clients to make requests for API data of other clients
(assuming they know their mac address), but that's already possible by
spoofing the address anyway.

Cheers,

Remi

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Jul 2019 13:24:03 +1000

This is one of the costs of this architecture.  If the external system (portal HTML, etc...) needs access to identifiers, then the API endpoint will have to decorate the URLs it provides.  That might mean having the API endpoint inside the network, where it can see source IP or BSSID or whatever is being used for identification.  

An external service won't be able to validate any identifier it receives in this way, so you might want to make the decoration a little more complex than a simple addition of `?ip=192.0.2.3`.  Of course, the worst I can think of (offhand) is that someone could pay for my network access.

On Mon, Jul 29, 2019, at 13:51, Remi NGUYEN VAN wrote:
> rules to know who is blocked / allowed (probably based on mac address 
> ?), and can advertise a single API URL through DHCP / RAs / 
> Link-Relation and generate redirects, but does not have capabilities to 
> serve login pages or the API: this is handled by another box upstream 
> which has more capabilities like handling payment pages etc, and holds 
> the SSL certs. Because the API uses HTTPS (contrary to lots of login 
> pages), the WLAN controller can't easily insert identity of the 
> requestor in the request and the API has no way to know who it's 
> replying to.
> 
> Since we can't advertise different addresses for different clients in 
> RAs, how about having the client add a session identifier in their API 
> requests ? Having the client add a mac address in an HTTP request 
> header field would be a solution. Many devices are using random 
> per-SSID mac addresses now, so this sounds like a reasonable identifier 
> for the device to give to the API server (which could get it anyway 
> through some complicated setup).. It would be possible for clients to 
> make requests for API data of other clients (assuming they know their 
> mac address), but that's already possible by spoofing the address 
> anyway.
> 
> Cheers,
> 
> Remi
> 
> 
> On Sat, Jul 27, 2019 at 8:04 AM Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >  Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
> Attachments:
> * smime.p7s

---

From: Chris Spencer <[email-masked]>
Date: Wed, 31 Jul 2019 04:44:33 +0100

Please forgive, I'm new to this group and trying to come up to speed.

Would not a feed of option 82 rather than create a new API work? option 82
can carry MAC/IP (it could create a GUID/UUID) and other location
identifiers? if the external portal could get a feed of this, the portal at
layer 3 could look up the device MAC from the option 82 elements by the IP?
or if the DHCP server is centralised along with the portal architecture and
DHCP relay is used on the local site?

-
DHCP Option 82 Overview

If DHCP option 82 is enabled on a VLAN or bridge domain, then when a
network device—a DHCP client—that is connected to the VLAN or bridge domain
on an untrusted interface sends a DHCP request, the switching device
inserts information about the client's network location into the packet
header of that request."

On Wed, 31 Jul 2019 at 04:24, Martin Thomson <[email-masked]> wrote:

> This is one of the costs of this architecture.  If the external system
> (portal HTML, etc...) needs access to identifiers, then the API endpoint
> will have to decorate the URLs it provides.  That might mean having the API
> endpoint inside the network, where it can see source IP or BSSID or
> whatever is being used for identification.
>
> An external service won't be able to validate any identifier it receives
> in this way, so you might want to make the decoration a little more complex
> than a simple addition of `?ip=192.0.2.3`.  Of course, the worst I can
> think of (offhand) is that someone could pay for my network access.
>
> > >  Michael Richardson <[email-masked] <mailto:
> [email-masked]>>, Sandelman Software Works

-- 

Chris Spencer (D.Sc.)
Chief Technology Officer
Global Reach Technology Inc.
------------------------------
t. +44 20 7831 5630  <+442078315630>x. 1107 m. +44 7894 391127
<+447894391127>
e. [email-masked]
w. www.globalreachtech.com
UK. 110 Cannon Street, London, EC4N 6EU
<https://www.google.com/maps/place/110+Cannon+St,+London+EC4N+6EU/@51.5108556,-0.0902022,17z/data=!3m1!4b1!4m5!3m4!1s0x48760353f58858c5:0xeb84b17451c1f57f!8m2!3d51.5108556!4d-0.0880135>
US. 6203 San Ignacio Avenue, San Jose, CA 95119
<https://www.google.com/url?q=https://goo.gl/maps/JzwN68rbeUL2&sa=D&ust=1520535483922000&usg=AFQjCNFwcEcNSH8GeM_bPRMmr6BPUfglGg>
------------------------------
Follow me on twitter @DrCSpencer <https://twitter.com/DrCSpencer>
Together lets #makewifibetter
<https://twitter.com/search?q=%23makewifibetter>
------------------------------
The contents of this message are private and confidential. Intended for the
exclusive use of the person named above and may be legally privileged.
Should you receive this message by mistake, please be advised that its use,
duplication or distribution is strictly prohibited. In any circumstances,
please contact us immediately upon receipt by telephone.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Jul 2019 13:56:23 +1000

If DHCP is used, then it is possible to customize the API URL to include per-device information.  In that case, the API could be remote.

However, an IPv6 RA has to contain information that is the same for every device in the network.

On Wed, Jul 31, 2019, at 13:44, Chris Spencer wrote:
> Would not a feed of option 82 rather than create a new API work? option 
> 82 can carry MAC/IP (it could create a GUID/UUID) and other location 
> identifiers? if the external portal could get a feed of this, the 
> portal at layer 3 could look up the device MAC from the option 82 
> elements by the IP? or if the DHCP server is centralised along with the 
> portal architecture and DHCP relay is used on the local site?
> 
> -
> DHCP Option 82 Overview
> network device—a DHCP client—that is connected to the VLAN or bridge 
> domain on an untrusted interface sends a DHCP request, the switching 
> device inserts information about the client's network location into the 
> packet header of that request."
> 
> 
> >  > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >  > > 
> >  > > Michael Richardson <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Sandelman Software Works
> Global Reach Technology Inc.t. +44 20 7831 5630  <tel:+442078315630>x. 
> 1107 m. +44 7894 391127 <tel:+447894391127>e. 
> [email-masked]. www.globalreachtech.comUK. 110 
> Cannon Street, London, EC4N 6EU 
> <https://www.google.com/maps/place/110+Cannon+St,+London+EC4N+6EU/@51.5108556,-0.0902022,17z/data=!3m1!4b1!4m5!3m4!1s0x48760353f58858c5:0xeb84b17451c1f57f!8m2!3d51.5108556!4d-0.0880135>US. 6203 San Ignacio Avenue, San Jose, CA 95119 <https://www.google.com/url?q=https://goo.gl/maps/JzwN68rbeUL2&sa=D&ust=1520535483922000&usg=AFQjCNFwcEcNSH8GeM_bPRMmr6BPUfglGg>Follow me on twitter @DrCSpencer <https://twitter.com/DrCSpencer>Together lets #makewifibetter <https://twitter.com/search?q=%23makewifibetter>The contents of this message are private and confidential. Intended for the exclusive use of the person named above and may be legally privileged. Should you receive this message by mistake, please be advised that its use, duplication or distribution is strictly prohibited. In any circumstances, please contact us immediately upon receipt by telephone.
>

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Wed, 31 Jul 2019 13:03:49 +0900

I think we can either try to solve this problem by having the client send
an identifier to the API, or state that the API needs to be hosted inside
the network.
If we go with option 2, I'm afraid many vendors may just rely on DHCPv4 or
Link-Relation redirects to give different URLs based on the client, which
would hurt IPv6 adoption. So I'm wondering if option 1 (for example having
the client send an identifier in the host header of the API request) might
be strategically better.

Cheers,

Remi

On Wed, Jul 31, 2019 at 12:56 PM Martin Thomson <[email-masked]> wrote:

> If DHCP is used, then it is possible to customize the API URL to include
> per-device information.  In that case, the API could be remote.
>
> > >  An external service won't be able to validate any identifier it
> receives in this way, so you might want to make the decoration a little
> more complex than a simple addition of `?ip=192.0.2.3`. Of course, the
> worst I can think of (offhand) is that someone could pay for my network
> access.
> > >
> > >  > <[email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> > >  > >
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>, Sandelman Software Works
> > <
> https://www.google.com/maps/place/110+Cannon+St,+London+EC4N+6EU/@51.5108556,-0.0902022,17z/data=!3m1!4b1!4m5!3m4!1s0x48760353f58858c5:0xeb84b17451c1f57f!8m2!3d51.5108556!4d-0.0880135>US.
> 6203 San Ignacio Avenue, San Jose, CA 95119 <
> https://www.google.com/url?q=https://goo.gl/maps/JzwN68rbeUL2&sa=D&ust=1520535483922000&usg=AFQjCNFwcEcNSH8GeM_bPRMmr6BPUfglGg>Follow
> me on twitter @DrCSpencer <https://twitter.com/DrCSpencer>Together lets
> #makewifibetter <https://twitter.com/search?q=%23makewifibetter>The
> contents of this message are private and confidential. Intended for the

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 12:29:15 -0400

Chris Spencer <[email-masked]> wrote:
    > elements by the IP?  or if the DHCP server is centralised along with
    > the portal architecture and DHCP relay is used on the local site?

Option 82 is usually inserted by a DHCP relay when forwarding to a
centralized DHCP server.  It certainly could be used to customize the URL,
but in many systems this isn't going to work.

In a vast majority of "coffee shop" systems, the DHCP/RA function occurs on
premises in the router there, but the captive portal is out in the "cloud".
This is particularly prevalent in the smallest multisite installations
(10 locations across a single city), and the biggest multisite installations
("Harbucks" with 10,000 locations) where the operation of the captive portal
itself is outsourced to another company, or just centralized.

It probably occurs less in places like airports, hotels and enterprises where
there is more local operational clue.

So I just don't see how option 82 helps with IPv6 RAs.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Nicolas Mailhot <[email-masked]>
Date: Wed, 31 Jul 2019 20:20:15 +0200

> but in many systems this isn't going to work.

[snip]

> there is more local operational clue.

In entrerprises the dhcp layer is mostly owned by desktop IT (ADs, in
the hands of people still stuggling to come to terms with the way
Microsoft adopted networking and the cloud with a vengeance) while
access to the internal network (or from the "safe" internal network to
the wild internet, or from low-security visitor networks to high-
security internal networks) is managed by network or security teams.

Network/security teams will want to plop the security portal in a
single tighly controled place (a datacenter, or a set of datacenters
for redundancy), while local/desktop IT would not care less about
security considerations (but then, they are not asked to care about
them).

Therefore, deep collaboration between local networking and the portal
is wishful thinking. The security dialog has to happen between the
client and the central portal, with as little constrains and smartness
as possible delegated to the local networking kit (ideally, just let
everyone talk to the portal, and let IP/Macs/whatever requires as
little effort as possible to identify a system talk to other network
ranges, as long as they match the whitelist published by the central
portal for those ranges).

-- 
Nicolas Mailhot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 17:00:45 -0400

Nicolas Mailhot <[email-masked]> wrote:
    >> It probably occurs less in places like airports, hotels and
    >> enterprises where there is more local operational clue.

    > security internal networks) is managed by network or security teams.

I'm not sure why you are bringing up desktop IT when I mention DHCPv4.
In an enterprise captive portal use, I would expect it would be for visitors.

The APs would have a second ESSID, and this would be operated by the
network/security team. Whether they do DHCP locally or backhauled, would be
their business, not desktop IT?   Or are you saying that someone in desktop
IT would say, "WE HAVE TO DO ALL DHCP", just because silos?

    > portal for those ranges).

If the Captive Portal Enforcement Point is not on the AP itself, but in some
part of the network, then I guess the need for colloboration between wifi
people and network people is less.  Network people would simply have all the
guest traffic on some VLAN, do nothing on the APs themselves (other than VLAN
tagging).

What is your preference: does the client API have to have the client
self-identify, or do we have to find a way to send unique URLs in IPv6 RAs?