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

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=
40google.com@dmarc.ietf.org> wrote:

> On Mon, Jul 22, 2019 at 4:49 PM Martin Thomson <mt@lowentropy.net> 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.
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>