[Kea-users] Reaction to Option82

[Marcin Siodelski]

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