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

[David Bird <[e-mail]>]

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=
[e-mail]> 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=[e-mail]
> <[e-mail]>> 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=
>> [e-mail] <[e-mail]>> wrote:
>>
>>> 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.
>>> _______________________________________________
>>> Captive-portals mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>