[Oisf-devel] RFC: vlan_id in flow tracking

[Anoop Saldanha]

On Mon, Apr 8, 2013 at 9:10 PM, Victor Julien <victor at inliniac.net> wrote:
> On 04/08/2013 04:45 PM, Anoop Saldanha wrote:
>> On Mon, Apr 8, 2013 at 7:17 PM, Eric Leblond <eric at regit.org> 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.
>>>
>>>> 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.
>>>
>>> By the way, tagging host in the same way will be needed (thinking to
>>> threshold mainly).
>>>
>>
>> For 1 direction-only tagged packets we shouldn't consider the tag
>> while computing the hash, should we?
>
> Right, the hash will fail. Problem is that we start hashing before we
> know that the other side won't have vlans.
>
>> Maybe provide a configuration to specify ipnets, and suricata won't
>> use the tag(while computing the hash) for packets matching that range?
>>
>
> I was thinking about just doing a global switch. Do we need something
> more specific?
>

Something like a negative range.

vlan:
    # if no value is set the entire range would be considered for hashing.
    # If a value is set, the said range won't be used for calculating hash.
    flow-hash-computation-range: 0.0.0.0/24

-- 
Anoop Saldanha