[ovs-dev] [IPv6 6/7] nicira-ext: Support matching IPv6 Neighbor Discovery messages.

Jesse Gross jesse at nicira.com
Sat Jan 22 21:22:34 UTC 2011


On Sat, Jan 22, 2011 at 12:58 PM, Justin Pettit <jpettit at nicira.com> wrote:
> On Jan 22, 2011, at 8:24 AM, Ben Pfaff wrote:
>
>> On Sat, Jan 22, 2011 at 2:49 AM, Justin Pettit <jpettit at nicira.com> wrote:
>>> On Jan 21, 2011, at 2:56 PM, Ben Pfaff wrote:
>>>> Also in parse_icmpv6(), what's the proper handling of an ND message with
>>>> duplicate ND_OPT_SOURCE_LL_ADDR or ND_OPT_TARGET_LL_ADDR options?  This
>>>> could be a security issue, if different implementations do it
>>>> differently.
>>>
>>> Yeah, the same thing had occurred to me.  Here's the only thing RFC 2461 says about it:
>>>
>>>   Options in Neighbor Discovery packets can appear in any order;
>>>   receivers MUST be prepared to process them independently of their
>>>   order.  There can also be multiple instances of the same option in a
>>>   message (e.g., Prefix Information options).
>>>
>>> So, really, there's no answer about what to do in these circumstances that I could determine.
>>
>> Hmm, I'd be tempted to consider it an error and reject it.
>
> That is my initial reaction, too.  (My original set of IPv6 patches took a more aggressive stance towards only forwarding traffic that we know is good.)  However, I think we decided that we should really be acting in a "switch" mode (as opposed to an "IPS"-like mode) and only dropping packets that we know match a rule that the user defined and not performing any kind of sanitization.  I'm certainly open to discussing this further, though.

There's an implied false dichotomy here between switching and security
filtering.  In reality, it is possible to expose both to the
controller to configure as appropriate.  This is the reason why
encoding policy in the kernel is considered a serious design flaw as
it precludes correctness in a variety of situations.

The kernel should never drop valid L2 packets by itself, period.
Rejecting in this context does not mean dropping the packet.  It means
zeroing out the ND fields or otherwise indicating that a processing
error occurred.  That way someone trying to do switching can wildcard
those fields to let packets through and someone doing sanitization can
match on the invalid setting and drop it.

At the simplest level, in theory there could be an invalid flag at
each level: L3_invalid, L4_invalid, etc.  Any type of packet that you
think should be dropped would set this flag.  Since devices are not
supposed to look at layers above what they process, these fields would
be wildcarded while security devices would match and drop.  I'm not
actually proposing this as a solution as it is not very granular but
it illustrates that there is no conflict between security and
correctness.




More information about the dev mailing list