[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] customizing API URLs vs ???

Le mercredi 31 juillet 2019 à 12:29 -0400, Michael Richardson a écrit :
> Chris Spencer <[email protected]> wrote:
>     > 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?
> Option 82 is usually inserted by a DHCP relay when forwarding to a
> centralized DHCP server.  It certainly could be used to customize the
> URL,
> but in many systems this isn't going to work.


> It probably occurs less in places like airports, hotels and
> enterprises where
> there is more local operational clue.

In entrerprises the dhcp layer is mostly owned by desktop IT (ADs, in
the hands of people still stuggling to come to terms with the way
Microsoft adopted networking and the cloud with a vengeance) while
access to the internal network (or from the "safe" internal network to
the wild internet, or from low-security visitor networks to high-
security internal networks) is managed by network or security teams.

Network/security teams will want to plop the security portal in a
single tighly controled place (a datacenter, or a set of datacenters
for redundancy), while local/desktop IT would not care less about
security considerations (but then, they are not asked to care about

Therefore, deep collaboration between local networking and the portal
is wishful thinking. The security dialog has to happen between the
client and the central portal, with as little constrains and smartness
as possible delegated to the local networking kit (ideally, just let
everyone talk to the portal, and let IP/Macs/whatever requires as
little effort as possible to identify a system talk to other network
ranges, as long as they match the whitelist published by the central
portal for those ranges).

Nicolas Mailhot