Re: ctnetlink attributes [was: Re: [PATCH 1/2] updates for [nf|ct]netlink and event API]

[Amin Azez <azez@ufomechanic.net>]

Harald Welte wrote:

>On Mon, Jul 11, 2005 at 05:30:56PM +0100, Amin Azez wrote:
>  
>
>>I'm interested in adding MAC addr attributes and CTA_TUPLE_MAC; not just
>>because of my fixation with MAC addresses but also to use conntrack to
>>record flow data for non IP-related protocols.
>>    
>>
>
>ctnetlink MAC attributes are IMHO nonsense because there is no mac
>address tracking in conntrack.
>  
>
Indeed; I was proposing that it be so, I'm currently maintaining
conntrack patches where mac addresses are part of the conntrack.

>>I realise it is not the current intent of conntrack to do this, but as
>>much as conntrack solves the high-load problems of ulog, it is desirable
>>for it to keep counters for non-ip protocols.
>>    
>>
>
>Also, MAC address tracking doesn't really make sense since as an
>intermediate router there is no way that the assumption "source and
>destination mac never change" is ever valid.
>  
>
This is also true, there are few circumstances that the mac address
could change within the life of a connection and maintain the
connection, and it is uncertain in the scenario I proposed how this
should be handled.

>>As fast as protocol handlers can be devised it will become "conntrack"
>>again instead of "flowtrack", but the universal identifier between hosts
>>involved in a connection is the mac address and protocol. 
>>    
>>
>
>no.  you always only see the next hop mac address.  let's say you have
>an upsteram and a downstream router, then all your 'connections' would
>be between the same two mac addresses.
>  
>
The use would be limited to switched or transparently bridged networks
which is where most non-ip trafffic will be kept. I don't think this
particularly limits the use; many protocols do not employ a global
address space anyway.

SPX protocol uses the MAC address in conjunction with a network number
for node addressing.

>>The question is, how do others feel about conntrack tracking non-ip
>>connections? I intend to provide patches to do this if it is welcome.
>>    
>>
>
>nf_conntrack goes the way to layer-3-independent connection tracking.
>However, conntrack will remain to happen at layer3 and 4 (with minor
>exceptions to higher layers in the case of conntrack helpers).
>  
>
So you are not against tracking non-IP traffic as such?
I agree that it is ideal to break open the layer 3 addressing for use in
the conntrack tuple, I was suggesting using mac address and protocol as
a fallback when this was not available.

Amin