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

[Jesse Gross]

On Sat, Jan 22, 2011 at 3:18 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Sat, Jan 22, 2011 at 01:22:34PM -0800, Jesse Gross wrote:
>> 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.  [...]
>
> Just to confirm, yes, that's what I meant, for what it's worth.  Sorry
> for being vague.
>
>> 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.
>
> Well, we sort of have that flag in the Netlink branch.  If there's an
> Ethernet attribute that indicates an IPv4 header should be present, but
> there's no attribute for IPv4, then the IPv4 header was missing,
> truncated, invalid, etc.

Yes, I think what we have is better than I what I was saying here.  I
was just trying to reduce it down to the essentials.