[Kea-users] Reaction to Option82

[Михаил Ермаков]

Hi Marcin.

Thanks! It's really helpful!
> On 07.12.2015 11:53, Михаил Ермаков wrote:
>> Hi everybody.
>>
>> I'm working in ISP and we are decided to use KEA as main DHCP server
>> within the migration to IPoE. Everything is good! But...
>>
>> We plan to use Option82 to authorize and authenticate subscribers. Then
>> we're going to assign a private IP-address (like 10.10.10.1) and do some
>> NAT. The main goal is "port based authentication" where client's
>> MAC-address is not so important. When the subscribers change theirs
>> devices they are still valid for billing system because of "port based
>> authentication". So... can we use Option82 in KEA? For example, can we
>> allocate IP-address to subscriber based on Option82 (switch's
>> MAC-address and port number)? If we can, we'll be able to allocate one
>> and the same IP-address to subscriber even if the subscriber change
>> their device.
>>
>> I'm really hope you can understand my poor English. I'm not so good in
>> it ) Sorry.
>> <https://slovari.yandex.ru/authorize/en-ru>
>>
>>
> Hi,
>
> Current address allocation strategy in Kea assumes that the client's MAC
> address or client identifier (held in the client identifier option) is
> used. If there are both present, the client identifier is used by
> default. However Kea configuration allows for modifying this behavior so
> as client identifier is ignored and the MAC address is used as if no
> client identifier is present. But...
>
> we don't natively support a case when other information from the packet
> is used to identify a client, e.g. information from the relay agent
> option. I realize there are use cases for it, and I already heard that
> some networks desire this approach.
>
> Many of the non-standard behaviors can be implemented as extensions to
> Kea, also known as "hooks". Our "Developer's Guide" contains nice
> tutorial about using/implementing hooks:
>
> http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html
>
> The nice thing about hooks is that you can achieve almost any behavior
> of the server. The down side is that you'll need to write a code.
>
> Your case seem to need the following:
>
> - A new hook library which implements two hook points: 'buffer4_receive'
> and 'pkt4_send'. This is equivalent to writing a library which
> implements 2 functions. These functions have well defined API (take
> input and output DHCP message pointer as argument).
> - The 'buffer4_receive' code in your library would need to use the relay
> agent information to construct a new client identifier and replace
> client identifier sent by the client. The old client identifier will
> have to be stored or somehow attached to the DHCP message so as it can
> be later put back into the response to the client. When you replace
> client identifier in the input message the server will use this new
> client identifier when further processing a message.
> - The 'pkt4_send' hook code in your library would need to put back an
> old client identifier into the response message, so as the client can
> recognize that this response is targeted to it.
>
> Now, once you have this library in place and you configure the server to
> load it, the server will call your functions for each packet it
> processes. That way your functions influence the packet processing.
>
> I don't have any proof of concept code for this, but it should work just
> fine.
>
> Let me know if I can help more on this.
>
> Marcin Siodelski
> DHCP Software Engineer
> ISC