[Oisf-devel] RFC: vlan_id in flow tracking

[Chris Wakelin]

On 08/04/13 13:45, Victor Julien wrote:
> On 04/08/2013 02:02 PM, Chris Wakelin wrote:
>> On 08/04/13 12:44, 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.
>>> For now, I would say the best approach may be to use the outer VLAN id
>>> as tag in flow. But It might only be my way of seeing thing, so a choice
>>> could be done via a configuration variable.
>>>
>>>> - there are reports of broken switches (Chris) that only append vlan
>>>> tags to one direction of the flows. To handle this correctly the vlan id
>>>> tracking would have to be optional
>>>
>>> We have to force people to upgrade their switches. It is good for the
>>> economy! Seriously, VLAN tracking has to be optional even to address the
>>> issue with multiple layers of VLAN.
>>>
>>
>> Alas Extreme 10GB border switches aren't cheap, and tagging only one
>> direction in a mirrored port is "by design" apparently. Presumably it's
>> to mark the direction and if they tagged both directions but with a
>> different VLAN tag, it would be just as awkward for us. We wouldn't get
>> our border switches upgraded just to make it easier for IDS either. I
>> might just about be able to persuade the network manager to go for a
>> fibre tap instead though.
> 
> Just to make sure I understand how things work in your case.
> 
> 1. connection passing through border: one direction tagged, other not
>

Yes, from a port-mirror of all the traffic

> 2. connection on inside only: fully tagged?
> 

Yes, I think so, but at the moment we're only monitoring the borders
(three of them!)

At Will Metcalf's suggestion (ages ago) I modify the pf_ring.c kernel
module to ignore vlan_id in its hash calculations.

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094