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

[Remi NGUYEN VAN <[e-mail]>]

I think we can either try to solve this problem by having the client send
an identifier to the API, or state that the API needs to be hosted inside
the network.
If we go with option 2, I'm afraid many vendors may just rely on DHCPv4 or
Link-Relation redirects to give different URLs based on the client, which
would hurt IPv6 adoption. So I'm wondering if option 1 (for example having
the client send an identifier in the host header of the API request) might
be strategically better.

Cheers,

Remi


On Wed, Jul 31, 2019 at 12:56 PM Martin Thomson <[e-mail]> wrote:

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