[Kea-users] deny booting or ignore booting

[Ambauen Daniel (ID NET)]

Hi 

> 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.

+1

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.  

Regards
Daniel 

 
> 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.
>>  
>>  
>>  
>> Br,
>> Thomas
>>  
>> 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
>>> analyzed:
>>>  - 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.
>>> 
>>> Regards
>>> 
>>> 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
> https://lists.isc.org/mailman/listinfo/kea-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4315 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20190322/6bf5eee7/attachment.bin>