[Oisf-devel] RFC: vlan_id in flow tracking

[Victor Julien]

On 07/23/2013 02:27 PM, Victor Julien wrote:
> On 04/08/2013 06:21 PM, Victor Julien wrote:
>> On 04/08/2013 05:19 PM, Eric Leblond wrote:
>>> Hi,
>>>
>>> On Mon, 2013-04-08 at 16:53 +0200, Victor Julien wrote:
>>>> On 04/08/2013 03:47 PM, Eric Leblond wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, 2013-04-08 at 15:13 +0200, Victor Julien wrote:
>>>>>> On 04/08/2013 03:00 PM, Eric Leblond wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, 2013-04-08 at 14:35 +0200, Victor Julien wrote:
>>>>>>>> On 04/08/2013 01:44 PM, Eric Leblond wrote:
>>>>>>>>> Hi,
>>> ...
>>>>>>> where Network (private IP for example) may be shared among client. And
>>>>>>> if we have no luck, then we can cross beams and have two clients with
>>>>>>> same network under the same VLAN. 
>>>>>>
>>>>>> Right, I think I get the point. If we would have:
>>>>>>
>>>>>> [vlan 1][vlan 2][client net 1]
>>>>>> [vlan 2][vlan 2][client net 2]
>>>>>>
>>>>>> We might mix both as we first peel off the outer vlan and then have no
>>>>>> way of distinguishing between the 2 client nets anymore, right?
>>>>>
>>>>> Exactly!
>>>>>
>>>>>> So if we have multiple layers, we'd need multiple tags in our flow hashing?
>>>>>>
>>>>>> [vlan 1][vlan 2][client net 1]
>>>>>> [vlan 2][vlan 2][client net 2]
>>>>>>
>>>>>> Here both tag 1 and 2 would be needed to get flows for "client net 1"
>>>>>> and tag 2 and 2 would be needed to get "client net 2". Make sense?
>>>>>
>>>>> Yes, this is the best behavior. 
>>>>
>>>> RFC:
>>>> https://github.com/inliniac/suricata/commit/e2693b6ce6ae5f7e43da26b47fdc2220dc1c3fa5
>>>
>>> I've got few comments on it but to consider the perspective of MPLS
>>> support. In this case, we will have the MPLS label to separate
>>> clients/network in the same way has it is done with vlan id. Maybe we
>>> could use a pointer inside the flow structure to indicate the
>>> "separator" field. This would also be of use if we consider a set of GRE
>>> tunnels used to separate network.
>>
>> Not sure if we should consider MPLS at this time. We've discussed
>> several ways to support it, including a flow engine per label. We'll get
>> to that when the time is right :)
>>
>> Wrt GRE, I've been browsing my pcap collection, but I can't seem to find
>> something like a "vlan id" or "mpls label" in it. They "key" field isn't
>> it I think.
>>
>>>>>> In my patch I have a u16 for padding, so I could add support for dual
>>>>>> layer vlans easily. For more... well that would be more work. Maybe we
>>>>>> can just limit to 2 layers.
>>>>>
>>>>> From http://en.wikipedia.org/wiki/IEEE_802.1Q triple tagging is not
>>>>> standard.
>>>>
>>>> I added a check for this in my RFC patch above.
>>>
>>> It seems clean.
>>>
>>>>> By the way, tagging host in the same way will be needed (thinking to
>>>>> threshold mainly).
>>>>
>>>> Right. That is going to be interesting wrt IPrep :) Maybe I should move
>>>> iprep out of the hosts.
>>>
>>> Yes, multi-client is something that would result in some complex and
>>> huge work :)
>>
>> Yeah. Taking it a step at a time...
>>
> 
> I've added a little doc here:
> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/VLAN_Handling
> 
> Also, for the flow part I have created this PR:
> https://github.com/inliniac/suricata/pull/457 (bug 813 [1])
> 
> It includes a way to disable, set vlan.disabled to 'true' in the yaml.
> Testing and review is welcome!
> 
> [1] https://redmine.openinfosecfoundation.org/issues/813
> 

This work has now been merged into master. For Chris, to disable, add:

vlan:
  use-for-tracking: false

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------