[Oisf-devel] RFC: vlan_id in flow tracking

[Victor Julien]

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,
>>>>>
>>>>> On Thu, 2013-04-04 at 13:10 +0200, Victor Julien wrote:
>>>>>> (RFC: request for comments :))
>>>>>>
>>>>>> Suricata currently parses VLAN headers but doesn't really do anything
>>>>>> with them. This is obviously wrong in some cases, like in flow tracking.
>>>>>> There can be several vlan's on a network, where in each we see the same
>>>>>> 5-tuple. These shouldn't be mixed, but right now they can be.
>>>>>>
>>>>>> This patch tries to deal with it:
>>>>>> https://github.com/inliniac/suricata/commit/d755fdfdc4576057712ccdb70f1e3a17bfad901c
>>>>>>
>>>>>> There are a few open issues:
>>>>>>
>>>>>> - what to do in case of multiple layers of VLAN? We should probably be
>>>>>> taking the tunnel approach, where we create a fake packet
>>>>>
>>>>> If people are separating client networks by using first VLAN and if
>>>>> second VLAN is the one used in client network, the tunneling approach
>>>>> will not work.
>>>>
>>>> How do you mean? Each vlan id should be a unique network, right?
>>>
>>> Yes but I was thinking to this setup:
>>>
>>> | Client Vlan | Network VLAN | Datagram |
>>>
>>> If we do a tunnel and remove Client Vlan, the result is a multiclient
>>> packet:
>>>
>>> | Network VLAN | Datagram |
>>>
>>> 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

>> 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.

> 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.

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