conntrack manipulation

conntrack manipulation

[Nils Ohlmeier]

Hi all,

short question: is it possible to manipulate the entrys of the connection 
tracking (specialy adding and removing entrys) from user space?

In more details:
we try to get an over SIP signaled RTP stream (Voice over IP) through 
netfilter NAT. Some time ago we coded the fcpd (http://fcpd.berlios.de) which 
enables applications to maipulate packet filter and NAT rules. Now the SIP 
Express Router (http://www.iptel.org/ser) has support for this netfilter 
manipulation. But after long testing sessions we came to the following 
result:

phone1 ------ NAT ------- Internet ----- phone2

Phone1 starts a call to phone2 (INVITE message). Phone2 confirms the call (200 
OK message) after the user picked up and starts to send RTP packets to the 
public NAT address immediately. Now the comfirmation message hits the SIP 
proxy at the NAT box and will be processed. The proxy requests at the fcpd to 
insert S- and D-NAT rules for the RTP stream. The fpcd processes the request 
and inserts the rules.
But during all this process time the first RTP packets allready hit the NAT 
box. And if this packets are not droped by a rule, they will create a new 
conntrack entry. Now the insertion of the S/DNAT rules comes too late because 
all the packets of the stream will be intercepted by the conntrack before 
they hit our new rules.
Ok if the NAT box drops every packet which is not explictly allowed everything 
should work fine. But i think this is somewhat unrealistic, because most NATs 
will at least accept all packets from the private side to the Internet.

So my question is if it is possible that the fcpd deletes connection tracking 
entrys from the early packets. And if the fcpd could just insert a connection 
tracking entry for the stream it could omit the insertion of three normal 
rules (SNAT, DNAT and FORWARD).

I know that i could explicitly drop the packets from the stream until the 
connection is confirmed. But i dont like this idea because it complicates the 
rule handling from the fcpd a much. And because of the details in the SIP 
protocol we could only drop packets with some wildcards in the matching 
rules.

Thanks for any comments and ideas.
Greetings
  Nils Ohlmeier

Re: conntrack manipulation

[Jozsef Kadlecsik]

On Thu, 8 May 2003, Nils Ohlmeier wrote:

> short question: is it possible to manipulate the entrys of the connection
> tracking (specialy adding and removing entrys) from user space?

Short answer: no.

> phone1 ------ NAT ------- Internet ----- phone2
>
> Phone1 starts a call to phone2 (INVITE message). Phone2 confirms the call (200
> OK message) after the user picked up and starts to send RTP packets to the
> public NAT address immediately. Now the comfirmation message hits the SIP

How can the user (phone1) send RTP packets before receiving the 200 OK
message from phone2?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: conntrack manipulation

[Nils Ohlmeier]

On Friday 09 May 2003 14:36, Jozsef Kadlecsik wrote:
> On Thu, 8 May 2003, Nils Ohlmeier wrote:
> > phone1 ------ NAT ------- Internet ----- phone2
> >
> > Phone1 starts a call to phone2 (INVITE message). Phone2 confirms the call
> > (200 OK message) after the user picked up and starts to send RTP packets
> > to the public NAT address immediately. Now the comfirmation message hits
> > the SIP
>
> How can the user (phone1) send RTP packets before receiving the 200 OK
> message from phone2?

Not phone1 sends but phone2 sends RTP packets immediately after it send the 
'200 OK' to confirm that the user at phone2 picked up the hearer.
So the problem is basicly that the callee phone starts to send packets to fast 
(at least to fast for our solution).

It could also happen that that phone1 starts to send RTP packets before it 
received the '200 OK' if it received '183 Session progress' with a SDP body 
(which contains the IP and port of phone2). But this is not the normal case 
and makes no difference to the 200 case because we can insert the rules also 
on 183.

Greetings
  Nils Ohlmeier

Re: conntrack manipulation

[Jozsef Kadlecsik]

On Sat, 10 May 2003, Nils Ohlmeier wrote:

> On Friday 09 May 2003 14:36, Jozsef Kadlecsik wrote:
> > On Thu, 8 May 2003, Nils Ohlmeier wrote:
> > > phone1 ------ NAT ------- Internet ----- phone2
> > >
> > > Phone1 starts a call to phone2 (INVITE message). Phone2 confirms the call
> > > (200 OK message) after the user picked up and starts to send RTP packets
> > > to the public NAT address immediately. Now the comfirmation message hits
> > > the SIP
> >
> > How can the user (phone1) send RTP packets before receiving the 200 OK
> > message from phone2?
>
> Not phone1 sends but phone2 sends RTP packets immediately after it send the
> '200 OK' to confirm that the user at phone2 picked up the hearer.
> So the problem is basicly that the callee phone starts to send packets to fast
> (at least to fast for our solution).

Then enter the required rules when phone1 sends the command, without
waiting for a confirmation from phone2. If phone2 would refuse the
request, then delete the unnecessarily added rules.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: conntrack manipulation

[Nils Ohlmeier]

Hi Jozsef,

first of all thanks for thought and ideas.

On Monday 12 May 2003 09:35, Jozsef Kadlecsik wrote:
> On Sat, 10 May 2003, Nils Ohlmeier wrote:
> > Not phone1 sends but phone2 sends RTP packets immediately after it send
> > the '200 OK' to confirm that the user at phone2 picked up the hearer. So
> > the problem is basicly that the callee phone starts to send packets to
> > fast (at least to fast for our solution).
>
> Then enter the required rules when phone1 sends the command, without
> waiting for a confirmation from phone2. If phone2 would refuse the
> request, then delete the unnecessarily added rules.

For a call from internal to external (outbound) this would be possible if we 
insert DNAT rules with any source IP and port. But for inbound calls we have 
a problem, because with the SIP protocol you do not know the final 
destination (IP and port) if you see a traversing INVITE. So we can insert 
the DNAT rule only after we saw the SDP part of the 200 OK (or any other 1xx 
with a SDP body).

Regards
  Nils Ohlmeier

Re: conntrack manipulation

[Ian Latter]

Howdy,

  How, then, does  this differ from either the FTP conntrack+nat 
module?  Surely you just want to right a small connection tracker
that understands your phone protocol and relays connections
appropriately?



----- Original Message -----
>From: "Nils Ohlmeier" <lists@ohlmeier.de>
>To: "Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>
>Subject:  Re: conntrack manipulation
>Date: Mon, 12 May 2003 20:15:02 +0200
>
> Hi Jozsef,
> 
> first of all thanks for thought and ideas.
> 
> On Monday 12 May 2003 09:35, Jozsef Kadlecsik wrote:
> > On Sat, 10 May 2003, Nils Ohlmeier wrote:
> > > Not phone1 sends but phone2 sends RTP packets immediately after it send
> > > the '200 OK' to confirm that the user at phone2 picked up the hearer. So
> > > the problem is basicly that the callee phone starts to send packets to
> > > fast (at least to fast for our solution).
> >
> > Then enter the required rules when phone1 sends the command, without
> > waiting for a confirmation from phone2. If phone2 would refuse the
> > request, then delete the unnecessarily added rules.
> 
> For a call from internal to external (outbound) this would be possible if we 
> insert DNAT rules with any source IP and port. But for inbound calls we have 
> a problem, because with the SIP protocol you do not know the final 
> destination (IP and port) if you see a traversing INVITE. So we can insert 
> the DNAT rule only after we saw the SDP part of the 200 OK (or any other 1xx 
> with a SDP body).
> 
> Regards
>   Nils Ohlmeier
> 
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: conntrack manipulation

[Nils Ohlmeier]

Hi Ian,

On Tuesday 13 May 2003 01:35, Ian Latter wrote:
>   How, then, does  this differ from either the FTP conntrack+nat
> module?  Surely you just want to right a small connection tracker
> that understands your phone protocol and relays connections
> appropriately?

SIP differ in a lot points from FTP:
- it uses normaly UDP not TCP (although TCP is possible according to the 
newset RFC3261)
- it needs more then one related connection (ok thats not a problem any more)
- its a ASCII based protocol related with http
- it can contain hostnames instead of IP <- and thats the reason why it exist 
no conntrack helper and i do/will not write such a module

Regards
  Nils Ohlmeier