On 9/29/10 12:13 AM, Bhanu Gollapudi wrote:
> On Tue, 2010-09-28 at 15:34 -0700, Robert Love wrote:
>> On Tue, 2010-09-28 at 15:23 -0700, Bhanu Gollapudi wrote:
>>> On Wed, 2010-09-22 at 15:58 -0700, Robert Love wrote:
>>>
>>>>
>>>> This means that we need to compare the FC Frame's
>>>> destination FCID against the embedded FCID in the
>>>> destination MAC address. This patch checks the lower
>>>> 24 bits of the destination MAC address against
>>>> destination FCID in the Fibre Channel frame.
>>>>
>>>> For MAC validation the first line of defense is the
>>>> hardware MAC filtering. Each VN_Port will have a
>>>> unicast MAC addresses added to the hardware's
>>>> filtering table. The Ethernet driver should drop any
>>>> MACs not destined for a programmed MAC.
>>>
>>> If the NIC is in promiscous mode for some reason, the driver may not
>>> drop these packets, right?
>>>
>> Yes, that is true. I would argue that if the NIC is in promiscuous mode
>> then your system is compromised and checking the MAC is the least of
>> your problems.
>
> Even if not intentionally, NIC can go into promiscuous mode when running
> application like tcpdump or even connecting to wireshark.
IMHO, only promiscuous listeners should get packets in this case, the
current situation is a network stack bug/feature. It's always been that way
on Linux. FreeBSD handles this better.
BTW, I think its better to use tcpdump -p, which doesn't go promiscuous,
so you don't see frames in your trace that wouldn't have been received
otherwise.
>>>> This patch
>>>> adds a second line of defense that very specfically
>>>> compares an element in the FC frame against an element
>>>> in the Ethernet header, which is appropriate for the
>>>> FCoE layer.
>>>
>>> In which case, this check may not be sufficient. Am I missing something?
>>>
>> I don't think you're missing anything. ;)
>>
>> I think our options are either to do this check, do nothing or walk the
>> NPIV list. Walking the NPIV list is going to hurt performance with NPIV
>> on and I'm not sure this second level of validation is worth it. Doing
>> nothing doesn't make us spec compliant. This check at least makes us
>> spec compliant, doesn't hurt performance and does add some value.
>
> Probably. Since NIC will be directly connected to the FCF, we may not
> see the traffic which is not intended to be delivered to us, unless
> someone intentionally tests this. But there is a chance we end up
> processing wrong frame if that happens.
This is true of all protocols, including IP, isn't it? It could be considered
a problem with the network stack. The packet_type should be registered
for an interface and a MAC address and all the filtering should be done
at that layer. However, I think that would hurt performance too much.
I think the FCoE situation with this patch is OK.
It is, as you say, unlikely that we'll get wrong traffic.
It would have to have the same D_ID as us, and a different OUI, and
that's not valid on the same VLAN as other FCoE traffic. If someone
is intentionally trying to spoof things, they can just as easily
use the right MAC address, so there's no security issue here.
Regards,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
