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

[Tommy Pauly <[e-mail]>]

To that end, any enforcement of other traffic (such as normal web page loading) will not be carrying any session identifier, so only signals that are already present in the packets, such as the IP address, are effectively useful here.

Thanks,
Tommy

> On Jul 25, 2019, at 2:43 PM, Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>> wrote:
> On Mon, Jul 22, 2019 at 4:49 PM Martin Thomson <[e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> _______________________________________________
> Captive-portals mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals