Re: [GNUnet-developers] Binding to multiple IP addresses

[Christian Grothoff]

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

On Monday 25 November 2002 01:19 pm, Nathan Lutchansky wrote:
> After taking a look at the transport infrastructure in the GNUnet CVS, it
> appears that the core assumes that each transport will create no more than
> one HELO message. 

This is correct. 

> This artificially limits us to one addr/port binding
> with the UDP transport, preventing a GNUnet instance from advertising
> multiple IP addresses.  Is there a reason this was done, or was it just an
> artifact of the chosen API?

Neither nor. The choice does not prevent a GNUnet instance from advertising 
multiple IP addresses. It only means that the GNUnet peer must choose 
different protocol numbers and distinct HELO messages to advertise multiple
addresses. Note that "protocol number" refers to the number used internally to 
GNUnet, the IP protocol can be "UDP" in both cases.

There are two reasons for this. First, a receiving peer MUST verify that a 
HELO advertisement is valid by contacting the host at the address that is 
advertised. Only after the verification (by sending PING and receiving PONG) 
was successful, the HELO is stored and forwarded to other peers. If multiple 
addresses were advertised, the peer would have to verify ALL of them, 
increasing complexity, chances that the verification fails (50% message drop 
for 1 address means 50% verification probabiltiy for a single-address HELO, 
but 25% for a 2-address HELO), opportunities of attacks (trick peer into 
sending multiple messages, multiplying attacker bandwith effectivity). So 
there are a bunch of security considerations here.

Furthermore, it is much simpler for the core to have a "one transport, one 
HELO" paradigm to handle. Back to IPv4/IPv6. If you want to share a socket on 
a dual-stack kernel that advertises 2 IP addresses, you need to load 2 
transport modules (udp4, udp6) into the core. Then you can advertise 2 HELOs 
and get 2 transport protocol numbers. In your implementation (!), you can 
still share the socket -- how the udp4/udp6 transports are implemented 
*internally* is up to you. You may do some IPC, sharing of a third dynamic 
library that contains the actual socket code, whatever you need. 

> Also, I notice that UDP binds are done to the INADDR_ANY address, even
> though we know the correct address we should be sourcing packets from.  Is
> there any reason the UDP transport does not bind to the address given by
> getPublicIPAddress() in passivesock()?  I can think of several reasons
> a wildcard bind would cause problems, but can think of no reasons a
> specific bind would hurt anything...

getPublicIPAddress() can not be used since it may be the IP of the NAT box 
(and the NAT box may be confused about receiving UDP traffic that originates 
from the virtual network with the address of the NAT box on the Internet). 
getPublicIPAddress() is the address that IPv4 (!) transports are advertising. 
While it is often derived from the local network device, it may be different. 

Why should the wildcard cause problems? If I understand the specs correctly, 
the kernel will fill in the "real" local IP of the outbound network device 
into the IP header in this case, which should be exactly what we want. And 
for receiving, we want "ANY" since the UDP port is supposed to listen for 
traffic from anyone no matter from which IP.

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

iD8DBQE94m9l9tNtMeXQLkIRAq0GAKCJRG3EWKOSgBPnI6e8VS/VM/zEnQCeI+99
/sfqbnwWPD0z9xQPSpROcLM=
=Aabc
-----END PGP SIGNATURE-----