[Oisf-devel] RFC: vlan_id in flow tracking

[Eric Leblond]

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

BR,
-- 
Eric Leblond <eric at regit.org>
Blog: https://home.regit.org/