How exactly does RELATED work in Connection Tracking?

How exactly does RELATED work in Connection Tracking?

[Matthew Donofrio]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

Hi everyone.  Before I ask my question, I just want to alert everyone that I am newbie to Linux and the netfilter architecture.  OK, that being said, here's my question.  I'm trying to determine how exactly an incoming packet is determined to be RELATED to an existing connection in Connection Tracking.  For instance, how exactly does a TCP connection know that the packet is starting a new connection and this should be deemed RELATED?  What fields (for lack of a better word) are compared to come to this conclusion?  Thanks in advance.

-Matt

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: How exactly does RELATED work in Connection Tracking?

[Cedric Blancher]

Le mar 22/10/2002 à 07:48, Matthew Donofrio a écrit :
> I'm trying to determine how exactly an incoming packet is determined
> to be RELATED to an existing connection in Connection Tracking. For
> instance, how exactly does a TCP connection know that the packet is
> starting a new connection and this should be deemed RELATED?  What
> fields (for lack of a better word) are compared to come to this
> conclusion?

I am no Netfilter developper, but this is what I understood from all
I've read on the subject.

Connection tracking relies on data structures. In those, to be quick,
you have tuples that are used to recognise packets going both ways. A
tuple is a set of datas that caracterize a packet for Netfilter. Theses
tuples are used firstly to build conntrack table entries, and then to
try to match theses entries against further packets. That means when you
see a packet, you can calculate its own tuple, and then compare it to
the ones that are in data structures that represent current conntracked
flows.

When you load an ip_conntrack module, such as ip_conntrack_ftp, it
starts to look at specific network flows. For FTP conntrack, it looks at
every TCP connection destined to port 21. Then, it tries to spot data
connection negociation into them (PORT and OK that follows PASSIVE).
When spot, theses commands are parsed, and a tuple is extracted to match
the first packet of the rekated connection. As an example, when you see
parameters associated to PORT command, you are able to exactly know what
packet will initiate data connection. This extracted tuple is called an
expectation.

When a packet reaches the box, then Netfilter looks at it, extract from
the header its own tuple and then compares it to known tuples that are
part of current conntracked connections. If it matches one of theses
tuples, then it is ESTABLISHED. It is also compared to all expectations.
If it matches one expectation, then we know this packet is RELATED (and
if it does not match anything, it is NEW). Then, we can create a new
structure for him with tuples and so on and treat the flow as others.


Hope this 2 cents of euro will help you ;)

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security expert  - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: How exactly does RELATED work in Connection Tracking?

[Cedric Blancher]

Le mer 23/10/2002 à 17:57, Matthew Donofrio a écrit :
> The tuple is just the source address and destination address for a
> particular packet, correct?

No, because your box can have multiple different flows with the same
destination. A tuple as src address, dst address, layer 4 protocol and
layer 4 datas, such as src and dst ports for TCP or UDP.

> So is it safe to say that the  only fields that are compared for
> connection tracking are the source and destination addresses?

No it's not sufficient. you have to look at layer 4 datas.
 
> So, if a packet comes in and the source and destination addresses
> match an entry in the conntrack state table, then we can say that
> it is part of some ESTABLISHED connection.

It is established if its tuple (as defined below) matches an entry in
the conntrack table, i.e. if it is the same than the tuples associated
to entries.

Good reading for you are :

http://www.gnumonks.org/presentations/netfilter-knf2002/netfilter-knf2002.pdf
http://www.gnumonks.org/presentations/netfilter-internals-lt2002/netfilter-internals-lt2002.pdf

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: How exactly does RELATED work in Connection Tracking?

[Matthew Donofrio]

>Connection tracking relies on data structures. In those, to be quick,
>you have tuples that are used to recognise packets going both ways. A
>tuple is a set of datas that caracterize a packet for Netfilter. Theses
>tuples are used firstly to build conntrack table entries, and then to
>try to match theses entries against further packets. That means when you
>see a packet, you can calculate its own tuple, and then compare it to
>the ones that are in data structures that represent current conntracked
>flows.

>When a packet reaches the box, then Netfilter looks at it, extract from
>the header its own tuple and then compares it to known tuples that are
>part of current conntracked connections. If it matches one of theses
>tuples, then it is ESTABLISHED. It is also compared to all expectations.
>If it matches one expectation, then we know this packet is RELATED (and
>if it does not match anything, it is NEW). Then, we can create a new
>structure for him with tuples and so on and treat the flow as others.

The tuple is just the source address and destination address for a
particular packet, correct?  So is it safe to say that the  only fields that
are compared for connection tracking are the source and destination
addresses?  So, if a packet comes in and the source and destination
addresses match an entry in the conntrack state table, then we can say that
it is part of some ESTABLISHED connection.  Thanks again.

-Matt

Re: How exactly does RELATED work in Connection Tracking?

[Antony Stone]

On Wednesday 23 October 2002 4:57 pm, Matthew Donofrio wrote:

> >Connection tracking relies on data structures. In those, to be quick,
> >you have tuples that are used to recognise packets going both ways. A
> >tuple is a set of datas that caracterize a packet for Netfilter. Theses
> >tuples are used firstly to build conntrack table entries, and then to
> >try to match theses entries against further packets. That means when you
> >see a packet, you can calculate its own tuple, and then compare it to
> >the ones that are in data structures that represent current conntracked
> >flows.
> >
> >When a packet reaches the box, then Netfilter looks at it, extract from
> >the header its own tuple and then compares it to known tuples that are
> >part of current conntracked connections. If it matches one of theses
> >tuples, then it is ESTABLISHED. It is also compared to all expectations.
> >If it matches one expectation, then we know this packet is RELATED (and
> >if it does not match anything, it is NEW). Then, we can create a new
> >structure for him with tuples and so on and treat the flow as others.
>
> The tuple is just the source address and destination address for a
> particular packet, correct?

No.   For TCP and UDP packets the tuple also contains the source and 
destination port numbers.

> So is it safe to say that the  only fields
> that are compared for connection tracking are the source and destination
> addresses?

No, otherwise if a client connected to a server using http, and then set up a 
new connection to the same server by ssh (same IP addresses, different port 
numbers), they would appear to be the same connection !

> So, if a packet comes in and the source and destination
> addresses match an entry in the conntrack state table, then we can say that
> it is part of some ESTABLISHED connection.  Thanks again.

If a packet comes in and the source and destination addresses and port 
numbers match an entry in the conntrack state table (with source and 
destination either way round, to allow for reply packets) then we can say 
that it is part of some ESTABLISHED connection.   You're welcome.

Antony.

-- 

How I want a drink, alcoholic of course, after the heavy chapters
involving quantum mechanics.

 - 3.14159265358979