Re: GnomeMeeting STUN

Re: GnomeMeeting STUN

[Harald Welte]

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

On Wed, Dec 24, 2003 at 11:16:14AM +0100, Damien Sandras wrote:
> Hello Harald,

Hi Damien.  I'm Cc'ing your email to netfilter-devel, since there might
be other developers interested in a discussion about STUN.

> I hope you are going well and I already wish you a merry christmas and a
> happy new year :-)

thanks a lot.  My best wishes for christmas and happy new year in
return.

> I have a few questions for you if you don't mind. You probably guess
> that getting gnomemeeting (and voip apps in general) behind a NAT
> gateway is hard for average users for which even port forwarding is
> hard.

yes, unfortunately those protocols are not very NAT friendly.

> Cisco has come up with a solution called STUN, I suppose you know what
> it is. GnomeMeeting could get STUN support soon, but Linux Nat appears
> as being of type "Blocked" (RFC3489). 

The Linux >= 2.4.x implementation of NA(P)T is what the IETF tends to
call 'fully symmetric NAPT', i.e. the most sophisticated version of
network and port address translation.  

With old, 'more stupid' NA(P)T implementations in ipfwadm and ipchains,
you would be able to do STUN.

So it seems like linux is too advanced for the tricks that STUN tries to
do.  

netfilter/iptables would AFAICT interoperate quite well with what the
ITEF MIDCOM people are designing, though.

> So my question is: is there a way to make Linux NAT gateways work with
> STUN?

No, I honestly don't see any way.  
The fundamental principles behind the iptables NAT design are:

1) try to change as little information as possible
	i.e. we only do NAT as long as it is possible. port numbers
	 are only changed if absolutely necessarry.  Also, as opposed
	 to ipchains, you cannot tell that NAT is used just by looking
	 at the source port numbers.

2) try to use as little resources as possible
	this especially means that any given (srcport,srcip) tuple
	at the NAT gateway can be used for many different connections,
	as long as the (dstip,dstport) tuple differs

3) provide as much 'security' as possible
	we get this for free if we do '2)'.  This means we don't accept
	any incoming reply packets from a differnet srcip/srcport than
	the original request was sent to.

> Have things changed with 2.6 in terms of the way NAT works and that
> could influence gnomemeeting's behavior?

NAT didn't change at all between 2.4.x and 2.6.x, so there is no change
related to gnomemeeting.

I assume all we have to offer is ip_conntrack/nat_h323, which is in
patch-o-matic but has been reported not to work with gnomemeeting (but
with netmeeting) in the past ?  We'd be happy to receive any feedback
you would have regarding that subject.

> Thank you,
>  _      Damien Sandras

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GnomeMeeting STUN

[Damien Sandras]

Le mer 24/12/2003 à 15:38, Harald Welte a écrit :
> On Wed, Dec 24, 2003 at 11:16:14AM +0100, Damien Sandras wrote:
> > Hello Harald,
> 
> Hi Damien.  I'm Cc'ing your email to netfilter-devel, since there might
> be other developers interested in a discussion about STUN.
> 

That's indeed a nice clarification :)

[...]

> NAT didn't change at all between 2.4.x and 2.6.x, so there is no change
> related to gnomemeeting.
> 
> I assume all we have to offer is ip_conntrack/nat_h323, which is in
> patch-o-matic but has been reported not to work with gnomemeeting (but
> with netmeeting) in the past ?  We'd be happy to receive any feedback
> you would have regarding that subject.
> 

I will do my best. I already had sent some information to Joszef a long
time ago, but I think it was lost. 

The problem with the conntrack approach is that we will also have to do
the same kind of connection tracker for the SIP protocol :(

Thanks for the answer,

> > Thank you,
> >  _      Damien Sandras
-- 
 _      Damien Sandras
(o-     
//\     It-Optics s.a.
v_/_    GnomeMeeting: http://www.gnomemeeting.org/
        FOSDEM 2004:  http://www.fosdem.org
        H.323 phone:  callto:ils.seconix.com/dsandras@seconix.com

Re: GnomeMeeting STUN

[Harald Welte]

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

On Thu, Dec 25, 2003 at 05:48:42PM +0100, Damien Sandras wrote:
> > NAT didn't change at all between 2.4.x and 2.6.x, so there is no change
> > related to gnomemeeting.
> > 
> > I assume all we have to offer is ip_conntrack/nat_h323, which is in
> > patch-o-matic but has been reported not to work with gnomemeeting (but
> > with netmeeting) in the past ?  We'd be happy to receive any feedback
> > you would have regarding that subject.
> > 
> 
> I will do my best. I already had sent some information to Joszef a long
> time ago, but I think it was lost. 

please retransmit, or even better: submit it to bugzilla.netfilter.org.
This way it is not that likely to get lost again.

> The problem with the conntrack approach is that we will also have to do
> the same kind of connection tracker for the SIP protocol :(

IIRC, SIP was the reason for MIDCOM (and FCP, ...).  A conntrack/nat
helper for SIP will only work in a very small subset of SIP (no
hostnames, only IP addresses, no encryption).  Despite that fact,
somebody is already working on such a helper.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GnomeMeeting STUN

[Nils Ohlmeier]

Hello,

On Wednesday 24 December 2003 15:38, Harald Welte wrote:
> On Wed, Dec 24, 2003 at 11:16:14AM +0100, Damien Sandras wrote:
> > I have a few questions for you if you don't mind. You probably guess
> > that getting gnomemeeting (and voip apps in general) behind a NAT
> > gateway is hard for average users for which even port forwarding is
> > hard.
>
> yes, unfortunately those protocols are not very NAT friendly.
>
> > Cisco has come up with a solution called STUN, I suppose you know what
> > it is. GnomeMeeting could get STUN support soon, but Linux Nat appears
> > as being of type "Blocked" (RFC3489).
>
> The Linux >= 2.4.x implementation of NA(P)T is what the IETF tends to
> call 'fully symmetric NAPT', i.e. the most sophisticated version of
> network and port address translation.

The detected NA(P)T type depends on various factors. How long are the bindings 
in connection tracking and how fast/often the STUN clients retry to check 
their status. How many STUN clients are used behind the NAT.

> With old, 'more stupid' NA(P)T implementations in ipfwadm and ipchains,
> you would be able to do STUN.

You are able to do STUN behind any type of NA(P)T. Only the detection results 
and depending on that the choices on how you can proceed are diffenrent :)

> So it seems like linux is too advanced for the tricks that STUN tries to
> do.

Yes, STUN works well if you are sitting behind one of these small hardware 
boxes, because the experiences shows that most of them are 'full cone 
NAT' (which means an IP port combination on the NAT box accepts pakcets from 
any IP or port combination for this destination and delivers it to the 
private destination).
But with netfilter and if i'm not wrong with the BSD's STUN is no help (except 
that you can detect that you are lost :)

> netfilter/iptables would AFAICT interoperate quite well with what the
> ITEF MIDCOM people are designing, though.

If it ever gets launched.

> > So my question is: is there a way to make Linux NAT gateways work with
> > STUN?
>
> No, I honestly don't see any way.
> The fundamental principles behind the iptables NAT design are:
>
> 1) try to change as little information as possible
> 	i.e. we only do NAT as long as it is possible. port numbers
> 	 are only changed if absolutely necessarry.  Also, as opposed
> 	 to ipchains, you cannot tell that NAT is used just by looking
> 	 at the source port numbers.
>
> 2) try to use as little resources as possible
> 	this especially means that any given (srcport,srcip) tuple
> 	at the NAT gateway can be used for many different connections,
> 	as long as the (dstip,dstport) tuple differs
>
> 3) provide as much 'security' as possible
> 	we get this for free if we do '2)'.  This means we don't accept
> 	any incoming reply packets from a differnet srcip/srcport than
> 	the original request was sent to.

The best solution at the moment for 'symmetric NAT's' like Linux seems to be 
media relay in the public internet.
To be able to live just with STUN you had to change Netfilter back to the more 
"unsecure"  'full cone NAT' as with ipchains. Which will probably rejected by 
the Netfilter team :)

Greets
  Nils

Re: GnomeMeeting STUN

[Nils Ohlmeier]

On Friday 26 December 2003 01:26, Harald Welte wrote:
> On Thu, Dec 25, 2003 at 05:48:42PM +0100, Damien Sandras wrote:
> > The problem with the conntrack approach is that we will also have to do
> > the same kind of connection tracker for the SIP protocol :(
>
> IIRC, SIP was the reason for MIDCOM (and FCP, ...).  A conntrack/nat

Yes, that was one of the starting issues for MIDCOM.

> helper for SIP will only work in a very small subset of SIP (no
> hostnames, only IP addresses, no encryption).  Despite that fact,

Ok, there are currently AFAIK no SIP clients available (i'm not sure about the 
commerical ones) which supports SIP encryption. So thats probably a small 
problem.
Problematic is that hostnames or IPs are allowed in all header fields. Not 
many user agents use hostnames in the interesting header fields, especially 
if they are in a private network. But do you want to explain the 'normal' 
users that some phones will work and others not (or even worse some scenarios 
will work with one phone, but some other things will not work with the same 
phone).

> somebody is already working on such a helper.

Ohh, thats interesting. Who is trying to put a full SIP and SDP protocol 
parser into a NAT helper :) (i missed that) ?

Greets
  Nils

Re: GnomeMeeting STUN

[Harald Welte]

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

On Fri, Jan 02, 2004 at 08:37:24PM +0100, Nils Ohlmeier wrote:

> > So it seems like linux is too advanced for the tricks that STUN tries to
> > do.
> 
> Yes, STUN works well if you are sitting behind one of these small hardware 
> boxes, because the experiences shows that most of them are 'full cone 
> NAT' (which means an IP port combination on the NAT box accepts pakcets from 
> any IP or port combination for this destination and delivers it to the 
> private destination).
> But with netfilter and if i'm not wrong with the BSD's STUN is no help
> (except that you can detect that you are lost :)

fortunately (or unfortunately, depending on your viewpoint) an
increasing number of those 'small hardware boxes' start to use Linux.
If you buy recent 802.11g AP/router combo's with builtin switch and
sometimes even dsl-modem, they are very likely to run linux.
(linksys,belkin,buffalo, ...)
> To be able to live just with STUN you had to change Netfilter back to
> the more "unsecure"  'full cone NAT' as with ipchains. Which will
> probably rejected by the Netfilter team :)

probably ;)

> Greets
>   Nils

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GnomeMeeting STUN

[Harald Welte]

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

> But do you want to explain the 'normal' users that some phones will
> work and others not (or even worse some scenarios will work with one
> phone, but some other things will not work with the same phone).

yes, as opposed to commercail solutions, we don't need to give 'easy
answers' and can be honest.  If it only supports a certain subset, we
would certainly not claim that it supports all SIP variations.

> > somebody is already working on such a helper.
> 
> Ohh, thats interesting. Who is trying to put a full SIP and SDP protocol 
> parser into a NAT helper :) (i missed that) ?

Nikolai Dahlem <Nikolai.Dahlem@epygi.de>

> Greets
>   Nils

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GnomeMeeting STUN

[Jozsef Kadlecsik]

On Thu, 25 Dec 2003, Damien Sandras wrote:

> > I assume all we have to offer is ip_conntrack/nat_h323, which is in
> > patch-o-matic but has been reported not to work with gnomemeeting (but
> > with netmeeting) in the past ?  We'd be happy to receive any feedback
> > you would have regarding that subject.
>
> I will do my best. I already had sent some information to Joszef a long
> time ago, but I think it was lost.

No, it was not lost (if I did not respond to you, then I'm sorry): I put
h323-conntrack-nat aside as there was more important issues to be dealt
with. (And since then the ethereal code has been released with an H.323
parser, written in pure C...)

> The problem with the conntrack approach is that we will also have to do
> the same kind of connection tracker for the SIP protocol :(

It's not so bad at all: the nfnetlink/ctnetlink interface is about to be
finished, which will give us the full power to solve such problems, in the
most efficient way:

- we can keep the kernel modules for the simple cases
- can delegate the problem to userspace processes for complicated ones
  (DNS lookups, ets.)

Just time and some human resources are required :-).

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