Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Ticket 3618 and processing of corrupt options and
sub-options (Francis Dupont)
2. Re: Ticket 3618 and processing of corrupt options and
sub-options (Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Tue, 09 Jun 2015 16:36:20 +0000
From: Francis Dupont <[email protected]>
To: Shawn Routhier <[email protected]>
Cc: Kea Dev List <[email protected]>
Subject: Re: [kea-dev] Ticket 3618 and processing of corrupt options
and sub-options
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Shawn Routhier writes:
> 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-optio
> n is corrupt.
=> when I addressed the ticket 3618 I tried to create a consistent policy
which is:
- stop parsing (so not drop) of a packet which has a corrupt option
- raise an exception (so drop) when a packet has a corrupt sub-option
This was based on:
- a comment at the parsing caller saying partial parsing is accepted
- the fact that any corrupt known option with a not matching expected
internal structure (e.g., 6 bytes for an IPv4 address array) raises
an exception
I extended the second point to sub-options have to parse.
Now the ticket is no merged, there are still some arguable points
(including this one), and IMHO the policy should be to drop any corrupt
packets, including packets which don't parse up to their end.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Wed, 10 Jun 2015 07:03:59 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Shawn Routhier <[email protected]>, Kea Dev List <[email protected]>
Subject: Re: [kea-dev] Ticket 3618 and processing of corrupt options
and sub-options
Message-ID:
<ab94b0b675bdf14189cd5a861db36c841954e...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
> 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.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 15, Issue 2
**************************************
