[Kea-users] deny booting or ignore booting
Ambauen Daniel (ID NET)
daniel.ambauen at id.ethz.ch
Fri Mar 22 14:00:03 UTC 2019
> Installing a NAC for that purpose solely, would be overkill :)
> But when you have 35,000 devices, I would presume you already had some sort of NAC, to control/verify who’s on your network.
> That being 802.1x, Mac auth or CWP.
Well, we see over 40’000 devices in our network and we are using IEEE 802.1x.
From my point of view the network access control is definitely not a task of the DHCP service.
> From: Munroe Sollog <mus3 at lehigh.edu>
> Date: Friday, 22 March 2019 at 13.03
> To: Thomas Andersen <than at itu.dk>
> Cc: Francis Dupont <fdupont at isc.org>, "KEA-Users (kea-users at lists.isc.org)" <kea-users at lists.isc.org>
> Subject: Re: [Kea-users] deny booting or ignore booting
> While I appreciate the suggestion. Installing a NAC to accomplish similar functionality to one line of configuration in our DHCP server is kind of silly.
> On Fri, Mar 22, 2019 at 7:58 AM Thomas Andersen <than at itu.dk> wrote:
>> Do you have a NAC or is it open network?
>> I would prefer deny it when entering the network, not when asking for DHCP.
>> From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Munroe Sollog <mus3 at lehigh.edu>
>> Date: Friday, 22 March 2019 at 12.42
>> To: Francis Dupont <fdupont at isc.org>
>> Cc: "KEA-Users (kea-users at lists.isc.org)" <kea-users at lists.isc.org>
>> Subject: Re: [Kea-users] deny booting or ignore booting
>> Perhaps random wasn't a good choice of words. Given a MAC address we need a way of ensuring it does not DHCP. I'm open to alternatives to the ignore/deny booting function. Some sort of client classification?
>> On Thu, Mar 21, 2019 at 7:43 PM Francis Dupont <fdupont at isc.org> wrote:
>>> Munroe Sollog writes:
>>> > isc dhcpd supports the concept of "deny booting" or "ignore booting". Kea
>>> > does not seem to support this concept.
>>> => this feature is not supported by Kea but you have other ways to get
>>> the same effect.
>>> > >From time to time we need to ensure that a random device does not get a
>>> > valid lease and is thus prevented from accessing our network (we enforce
>>> > DHCP at the access layer). I found this:
>>> => as ISC DHCP booting keyword has a meaning only in a host reservation
>>> it is useless for a random device which by definition has no known
>>> identifier. Note if you want to ban unknown devices both ISC DHCP and
>>> Kea (since 1.5) provide a known/unknown client classification.
>>> > http://oldkea.isc.org/ticket/5229
>>> => replaced by https://gitlab.isc.org/isc-projects/kea/issues/239
>>> This ticket is a migration ticket: all features of ISC DHCP were
>>> - some can be translated (*) to Kea
>>> - some are candidate to be added to Kea
>>> - some have low interest (too specific, obsolete or unused, etc) (**)
>>> (*) There is a piece of software named the Migration Assistant which
>>> helps to translate ISC DHCP configurations to Kea. It is still in
>>> development but as we are looking for config samples to test and
>>> improve it you can contact us to know more...
>>> (**) #239 enters in the last category (priority low), the MA code emits
>>> a "no concrete usage known?" message when it finds the booting keyword.
>>> > I'm not sure what to make of this, but I tried creating a host reservation
>>> > without an IP address and kea errors with:
>>> > specified reservation for DUID: hwtype=1 00:50:56:bf:d7:a5 must include at
>>> > least one resource, i.e. hostname, IPv4 address, IPv6 address/prefix,
>>> > options
>>> => yes if you have no address (nor prefix in IPv6) you need a hostname.
>>> Note here a host reservation is perhaps not the best feature: what you
>>> want is some kind of access list and for a negative access list a client
>>> class is better. Host reservations and KNOWN/UNKNOWN are faster for
>>> a positive (and large) access list.
>>> Francis Dupont <fdupont at isc.org>
>> Munroe Sollog
>> Senior Network Engineer
>> munroe at lehigh.edu
> Munroe Sollog
> Senior Network Engineer
> munroe at lehigh.edu
> Kea-users mailing list
> Kea-users at lists.isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4315 bytes
Desc: not available
More information about the Kea-users