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

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