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

[Lorenzo Colitti <[e-mail]>]

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

> > 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.
>
> 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.

> 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.
>

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.