HTTP connection tracking

HTTP connection tracking

[Jan Engelhardt]

Hi,

a user in irc came up with the following scenario:

- home router is connected to two ISPs with different IP addresses and 
  does round-robin or some other form of packet scheduling.

- in such a setup, one generally uses MARK/CONNMARK to make sure that 
  packets of a certain connection always leave through the same device 
  through which the first packet was sent. (This is required to not 
  break TCP connections.)

But how can we make sure that arbitrary connections which are defined as 
related, can be sent through the same device? Think of a website which, 
when the user is logged in, requires that all HTTP and HTTPS connections 
that will be made by the user, must come from the same IP address.

Connection helpers seemed like a good idea at first, since expected 
connections inherit the connmark value of the original connection. 
However, once an expectation is set up, there is no way to set up 
another right after one expectation has been confirmed.

The stomper approach that seems left is to write a target extension that 
collects destination IP addresses (on IP_CT_NEW) and the mark value of 
the packet, or restores the mark value from the collection cache on 
!IP_CT_NEW.

There got to be a better way. What's Netfilter capable of I don't 
know yet?

Re: HTTP connection tracking

[Patrick McHardy]

Jan Engelhardt wrote:
> Hi,
> 
> a user in irc came up with the following scenario:
> 
> - home router is connected to two ISPs with different IP addresses and 
>   does round-robin or some other form of packet scheduling.
> 
> - in such a setup, one generally uses MARK/CONNMARK to make sure that 
>   packets of a certain connection always leave through the same device 
>   through which the first packet was sent. (This is required to not 
>   break TCP connections.)
> 
> But how can we make sure that arbitrary connections which are defined as 
> related, can be sent through the same device? Think of a website which, 
> when the user is logged in, requires that all HTTP and HTTPS connections 
> that will be made by the user, must come from the same IP address.
 >
> Connection helpers seemed like a good idea at first, since expected 
> connections inherit the connmark value of the original connection. 
> However, once an expectation is set up, there is no way to set up 
> another right after one expectation has been confirmed.

Why not?

Re: HTTP connection tracking

[Jan Engelhardt]

On Monday 2008-07-07 16:20, Patrick McHardy wrote:
>>
>> Connection helpers seemed like a good idea at first, since
>> expected connections inherit the connmark value of the original
>> connection. However, once an expectation is set up, there is no
>> way to set up another right after one expectation has been
>> confirmed.
>
> Why not?
>
Hm, so this is possible through the conntrack notifier chain?
Could this be prone to races -- windows where no exp is set up
but a connection is already made?

- core#1 create tcp packet (src:1024 -> dst:80)
- core#1 send off, conntrack hook sees it
- core#2 creates expectation (src:0 -> dst:80)
- core#2 create tcp packet (src:1025 -> dst:80)
- core#2 send off, conntrack sees it, confirms exp.
- core#3 create tcp packet (src:1026 -> dst:80)
- core#3 no expectation yet => bad
- core#2 notification delivered, exp. (src:0 -> dst:80) created

Re: HTTP connection tracking

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2008-07-07 16:20, Patrick McHardy wrote:
>>> Connection helpers seemed like a good idea at first, since
>>> expected connections inherit the connmark value of the original
>>> connection. However, once an expectation is set up, there is no
>>> way to set up another right after one expectation has been
>>> confirmed.
>> Why not?
>>
> Hm, so this is possible through the conntrack notifier chain?

Why the notifier chain? You can use expectfns for that.

> Could this be prone to races -- windows where no exp is set up
> but a connection is already made?
> 
> - core#1 create tcp packet (src:1024 -> dst:80)
> - core#1 send off, conntrack hook sees it
> - core#2 creates expectation (src:0 -> dst:80)
> - core#2 create tcp packet (src:1025 -> dst:80)
> - core#2 send off, conntrack sees it, confirms exp.
> - core#3 create tcp packet (src:1026 -> dst:80)
> - core#3 no expectation yet => bad
> - core#2 notification delivered, exp. (src:0 -> dst:80) created

Expectation registration, notifier calls and expectfn calls
are all synchronous, so there should be no race.