[Captive-portals] customizing API URLs vs ???

[Michael Richardson <[e-mail]>]

{trying to get this into it's own thread}

Remi NGUYEN VAN <reminv=[e-mail]> wrote:
    > 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.

It's relatively easy to customize the URL that a local DHCPv4 server gives out.
Yes, it could also be done by a DHCPv4 relay (with option 82).

As you identify, this hurts enabling IPv6 in captive portals.

An advantage of having the URL change is that the token that is added can be
opaque to the client.  Something encrypted.  It could even be a JWT.  The
client can't screw with the token to attempt to do API calls for a different
client.

If we go with something the client has to make up and provide (which I also
prefer), then we have to worry about how authentic it is.  That at least
means that the client has to POST it's info to the captive portal API, and
then get back some things that identify it for subsequent API calls.  That's
normal web interaction stuff, so not terribly innovative, but we do need to
think about this.

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