gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Re: [Help-gnunet] Re: udp traffic on port 65535


From: Christian Grothoff
Subject: [GNUnet-developers] Re: [Help-gnunet] Re: udp traffic on port 65535
Date: Tue, 20 Aug 2002 13:33:39 -0500
User-agent: KMail/1.4.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 20 August 2002 01:14 pm, David Hansen wrote:
> On Mon, Aug 19 at 17:55 Christian Grothoff wrote:
> > Port 65535 is also used for fragmented packets. I kind of doubt that
> > you've really got a kernel bug. What's the MTU of your network? How did
> > you get the portnumber?
> >
> > On Monday 19 August 2002 06:49 am, Peter Presslein wrote:
> > > Am Dienstag, 6. August 2002 04:23 schrieb Christian Grothoff:
> > >
> > > Hello again :-)
> > >
> > > > > since i installed gnunet 0.4.4 i have a lot of udp traffic
> > > > > on port 65535 going outside to other nodes.
>
> I just realized that i've the same problem...
>
> $IPCHAINS -A input -f -i $EXTDEV -l -j ACCEPT
>
> seems to help. But i dont know if this might be a security risk.

Well, that's what I figured, too. From the ipchains man-page:

NOTES
      Fragments are handled differently.  All fragments after the first used 
to be let through (which is usually safe); they can now be filtered.   This  
means
       that you should probably add an explicit rule to accept fragments if 
you are converting over.  Also, look for old accounting rules which check for 
source
       and destination ports of 0xFFFF (0xFF for ICMP packets) which was the 
old way of doing accounting on fragments.

- ------

since an MTU of 1492 will mean that GNUnet traffic would be fragmented, that 
explains the problem very well. While I don't see a particular security risk 
with letting through fragments, there are solutions:

a) a stateful firewall (iptables, 2.4 kernel) should handle the case much
    better
b) advertise MTU in the GNUnet handshake and automagically reduce to
    that size. This would increase the efficiency of the system and solve the
    problem at the same time. The code can not handle this at the moment,
    though. Maybe something to keep in mind for the future.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9YouD9tNtMeXQLkIRAglTAJ9IFfNsgNSAq/WDchaL8aDA+MvymgCgiFMk
O6NGzba3rmglrLVOyfjGdSA=
=cICP
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]