-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 21 May 2004 22:10, Ole Tange wrote:
> On Fri, 21 May 2004, Roger Oksanen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Friday 21 May 2004 16:44, Ole Tange wrote:
> > > On Wed, 19 May 2004 20:32:08 +0100, Toad wrote:
> > > > and most of the rest are
> > > > behind NATs which the user doesn't properly work around. :)
> > >
> > > Is there any reason why we cannot use STUN to avoid the NAT
> > > problems? It ought to be fairly simple to encapsulate the
> > > TCP-packets in UDP.
> >
> > Tunneling packets in UDP when both hosts are behind NAT has the
> > following problems:
> > * Generic NAT tunneling implementations don't work; They require
> > that one host is on a routable address.
> > * Tunneling TCP requires a device driver on every platform (see the
> > Mobile-IP RFC for NAT tunneling).
> > => This can be solved by running a protocol stack in user space
> > (i.e. in fred).
> > * Both ends need to know each others public (NAT) IP address.
> > * Both ends need to do the "punch hole in NAT"
> > - The node (A) that wants to contact the other node (B)
> > must insert a message intended for B, so that B can punch
> > a hole in the NAT.
> > - One cannot punch a hole in the NAT so that every IP is allowed.
> > - Since NAT changes the source port number. A would have
> > to send the initializing UDP packet to every port on B
> > (essentially port scan B).
> > - It might be that the hole that B punched through, only
> > accepts incoming UDP packets from a specific UDP port
> > => B has to punch holes for every possible port that
> > A:s NAT produces source ports for.
> >
> > ===> Ouch. Won't work :(
>
> Read RFC-3489 and become enlightened.
I read it. And I can't say I have changed my mind. To use the
terminology found in the RFC:
The "port restricted cone nat" is the problem I tried to describe in my
post. STUN does not solve that problem:
The binding acquisition usage of STUN does not work for all NAT
types. It will work for any application for full cone NATs only.
For restricted cone and port restricted cone NAT, it will work for
some applications depending on the application. Application
specific processing will generally be needed. For symmetric NATs,
the binding acquisition will not yield a usable address. The
tight dependency on the specific type of NAT makes the protocol
brittle.
=> "Application specific processing" generaly looks like it needs
external support, such as a server with a public IP forwarding the
traffic between the two hosts.
It is in my belief that "port restricted cone nat" is the most common
NAT found (AFAIK Linux NAPT can be counted to this group). Next in line
would be the "symmetric NAT" that large ISP:s especially in Europe (due
to the lack of available IPv4 addressess) use. I wasn't even avare that
there are NAPT GW:s that don't track the IP address (restricted cone),
and I would find that as a serious security concern.. "Cone nat" should
work currently if fred is configured with the external ipAddress.
External IP address detection would also be easy to add.
If I have misunderstood something fundamental, please correct me.
> Or, if that is too much to ask,
> download/buy a SIP-phone and place a call from behind NAT to behind
> NAT (_this_ ought to enlighten you).
I'm a full time student, and thus I live on the small financial aid for
students (<300â / month). No way I'm going to afford a SIP phone ;)
Could describe the technology used in the SIP phone to penetrate the
both NAPT GW:s (assuming they are both "port restructed full cone")?
- --
Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990
CS Student at Helsinki University PGP id 1B125A3E
Homepage http://www.cs.helsinki.fi/u/raoksane/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFArqvj78OZUBsSWj4RAvQyAJ95k8gRnsRds+bypc4p1FJCRHx5BACgv2bF
xUpQ38DD7bJ8zn/IwX1zsPI=
=Tv/O
-----END PGP SIGNATURE-----
_______________________________________________
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]
