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

["Martin Thomson" <[e-mail]>]

If DHCP is used, then it is possible to customize the API URL to include per-device information.  In that case, the API could be remote.

However, an IPv6 RA has to contain information that is the same for every device in the network.

On Wed, Jul 31, 2019, at 13:44, Chris Spencer wrote:
> Please forgive, I'm new to this group and trying to come up to speed.
> 
> Would not a feed of option 82 rather than create a new API work? option 
> 82 can carry MAC/IP (it could create a GUID/UUID) and other location 
> identifiers? if the external portal could get a feed of this, the 
> portal at layer 3 could look up the device MAC from the option 82 
> elements by the IP? or if the DHCP server is centralised along with the 
> portal architecture and DHCP relay is used on the local site?
> 
> -
> DHCP Option 82 Overview
> If DHCP option 82 is enabled on a VLAN or bridge domain, then when a 
> network device—a DHCP client—that is connected to the VLAN or bridge 
> domain on an untrusted interface sends a DHCP request, the switching 
> device inserts information about the client's network location into the 
> packet header of that request."
> 
> 
> On Wed, 31 Jul 2019 at 04:24, Martin Thomson <[e-mail]> wrote:
> > This is one of the costs of this architecture. If the external system (portal HTML, etc...) needs access to identifiers, then the API endpoint will have to decorate the URLs it provides. That might mean having the API endpoint inside the network, where it can see source IP or BSSID or whatever is being used for identification. 
> > 
> >  An external service won't be able to validate any identifier it receives in this way, so you might want to make the decoration a little more complex than a simple addition of `?ip=192.0.2.3`. Of course, the worst I can think of (offhand) is that someone could pay for my network access.
> > 
> >  On Mon, Jul 29, 2019, at 13:51, Remi NGUYEN VAN wrote:
> >  > So to summarize, we've got a problem where the WLAN controller has some 
> >  > rules to know who is blocked / allowed (probably based on mac address 
> >  > ?), and can advertise a single API URL through DHCP / RAs / 
> >  > Link-Relation and generate redirects, but does not have capabilities to 
> >  > serve login pages or the API: this is handled by another box upstream 
> >  > which has more capabilities like handling payment pages etc, and holds 
> >  > the SSL certs. Because the API uses HTTPS (contrary to lots of login 
> >  > pages), the WLAN controller can't easily insert identity of the 
> >  > requestor in the request and the API has no way to know who it's 
> >  > replying to.
> >  > 
> >  > Since we can't advertise different addresses for different clients in 
> >  > RAs, how about having the client add a session identifier in their API 
> >  > requests ? Having the client add a mac address in an HTTP request 
> >  > header field would be a solution. Many devices are using random 
> >  > per-SSID mac addresses now, so this sounds like a reasonable identifier 
> >  > for the device to give to the API server (which could get it anyway 
> >  > through some complicated setup).. It would be possible for clients to 
> >  > make requests for API data of other clients (assuming they know their 
> >  > mac address), but that's already possible by spoofing the address 
> >  > anyway.
> >  > 
> >  > Cheers,
> >  > 
> >  > Remi
> >  > 
> >  > 
> >  > On Sat, Jul 27, 2019 at 8:04 AM Michael Richardson 
> >  > <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> >  > > 
> >  > > Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> >  > > > Is there a problem with saying that the portal server should identify the
> >  > > > device by IP address?
> >  > > 
> >  > > Tommy Pauly <tpauly=[e-mail]> wrote:
> >  > > > 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.
> >  > > 
> >  > > It's not obvious to me that you are talking about the same thing!
> >  > > The portal server *could* use IP address as the key by which to identify
> >  > > the device to the Captive Portal Enforcer.
> >  > > 
> >  > > That requires that the access to the Captive Portal Server to always
> >  > > be on the same side of a NAT44 as the client, and I don't think that is
> >  > > realistic given how these services are outsourced.
> >  > > 
> >  > > (In architecture-04, we have "Captive Portal Enforcement", which seems
> >  > > to be an activity, while the description is about a thing. So I think
> >  > > that either the word "Point" should be added, or Enforcement->Enforcer)
> >  > > 
> >  > > The Captive Portal Enforcer SHOULD enable traffic based upon the mapped
> >  > > L2 address, otherwise, there would have to be a new portal session for
> >  > > IPv4 and IPv6, and for each new IPv6 temporary/privacy address.
> >  > > I don't think we want that. It would also, I think, force the portal
> >  > > server to speak both v4 and v6.
> >  > > 
> >  > > The communication between Captive Portal Server and Captive Portal Enforcer
> >  > > COULD identify the client by L3 address, but I wouldn't want to build things
> >  > > that way, because it would result in a poor experience for returning users,
> >  > > such as sleepy phones, or hotel guests that might leave the hotel and then
> >  > > return later in the day, and expect their 24hr pass to just work, despite
> >  > > DHCP leases being much shorter.
> >  > > 
> >  > > --
> >  > > Michael Richardson <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>, Sandelman Software Works
> >  > > -= IPv6 IoT consulting =-
> >  > > 
> >  > > 
> >  > > 
> >  > > _______________________________________________
> >  > > 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
> >  > 
> >  > Attachments:
> >  > * smime.p7s
> > 
> >  _______________________________________________
> >  Captive-portals mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/captive-portals
> 
> 
> -- 
> Chris Spencer (D.Sc.)
> Chief Technology Officer
> Global Reach Technology Inc.t. [phone]  <tel:[phone]>x. 
> 1107 m. [phone] <tel:[phone]>e. 
> [e-mail]. www.globalreachtech.comUK. 110 
> Cannon Street, London, EC4N 6EU 
> <https://www.google.com/maps/place/110+Cannon+St,+London+EC4N+6EU/@51.5108556,-0.0902022,17z/data=!3m1!4b1!4m5!3m4!1s0x48760353f58858c5:0xeb84b17451c1f57f!8m2!3d51.5108556!4d-0.0880135>US. 6203 San Ignacio Avenue, San Jose, CA 95119 <https://www.google.com/url?q=https://goo.gl/maps/JzwN68rbeUL2&sa=D&ust=1520535483922000&usg=AFQjCNFwcEcNSH8GeM_bPRMmr6BPUfglGg>Follow me on twitter @DrCSpencer <https://twitter.com/DrCSpencer>Together lets #makewifibetter <https://twitter.com/search?q=%23makewifibetter>The contents of this message are private and confidential. Intended for the exclusive use of the person named above and may be legally privileged. Should you receive this message by mistake, please be advised that its use, duplication or distribution is strictly prohibited. In any circumstances, please contact us immediately upon receipt by telephone.
>