[kea-dev] Ticket 3618 and processing of corrupt options and sub-options

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Wed Jun 10 07:03:59 UTC 2015


> As part of the review of ticket 3618 I thought it might be interesting to see if the community had any feedback on how best to handle a corrupt option or sub-option in a packet.
> 
> Some of the options are:
> 1) drop the packet if it has a corrupt option or sub-option
> 2) drop the packet if it has a corrupt sub-option but continue processing the packet if an option is corrupt (ignoring that option).
> 3) attempt to continue processing the packet if either the option or sub-option is corrupt.
> 



>From my experience, vendors can do stupid things. And they do, most of them, at some point or another.
When it happens, and it's out there in the world on many end user devices, you can't just say "you've broken the RFC's, fix it". Even if they do, most of the users won't upgrade.

So I would say, be as tolerant as possible. Just ignore what you can't parse, as long as what remains is a valid DHCP request.

Ideally, this would be configurable, allowing administrators who wish so to be unforgiving.


Regards,
Nicolas.



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.



More information about the kea-dev mailing list