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

[Lorenzo Colitti <[e-mail]>]

Is there a problem with saying that the portal server should identify the
device by IP address?

On Mon, Jul 22, 2019 at 7:40 PM David Bird <dbird=
[e-mail]> wrote:

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