Re: [GNUnet-developers] [Gsoc 2015] Project proposal on GNUnet-over-ICMP

[Christian Grothoff]

Hi Wen,

I still doubt this will work with NAT at all, as incoming ICMP pings
will be bounced by the NAT and never reach the host with the peer.

If only one peer is behind NAT, you will still absolutely need the
ability to substitute the payload in the PONG for something else, so as
to get any transmission going to the NATed peer, and even then the
question is if the NATed peer will allow the PONG through if the payload
fails to match the PING.  Truncation is then just yet another
issue.

Please play with command-line / pcap / etc. tools as a proof-of-concept
now.  I would feel more comfortable with this if we had the following:

1) an "ICMP client" implementation that sends an ICMP ECHO request to
   an IP address given at the command line, with "Hello" in payload
2) an "ICMP server" implementation that sends an ICMP ECHO REPLY to
   an IP address given at the command line with "World" in payload

and us confirming for _some_ NAT box (we should have plenty within the
team) that when we run the client *behind* the NAT and send a packet
to an unrestricted server (i.e. one of our university systems), and
then use the ICMP server to send a "fake" reply back to the external
IP of the NAT, the "World" packet does cross the NAT.

We could use iptables to block the kernel's ICMP ECHO RESPONSE and
wireshark to confirm the receipt of the "world" ICMP ECHO RESPONSE.
That's the simplest scenario to demonstrate ICMP "works" with NAT.

For me, this is important to know as for I the networks I use, they
either have NAT involved or UDP/TCP are likely to work fine already.
Naturally, I don't know about China with its IPv6 deployment, so
if you have data that shows that ICMP will work in situations where
TCP/UDP will not work, I'm willing to be educated ;-).


My 2 cents

Christian

On 03/20/2015 05:24 PM, Wen Yuzhong wrote:
> Hi Christian,
> 
> My idea is encapsulating all the payload in the ICMP echo request packet,
> so upon the system on the other side receives the Ping, the system will
> response a Pong as normal, then the RAW socket interface will parse the
> payload of the incoming ICMP echo request, and give the data to the upper
> layer of GNUNet. For the firewall/NAT, this will be like a normal ICMP
> conversation. In this way every Ping is matched with a Pong, we don't need
> to deal with the duplicated Pong problem.
> 
> However, as the frequency of the packet sending goes high, the channel
> might be flooded by ICMP echo response packets. From my point of view, this
> transport service is for *extreme* situations, so the throughput is not the
> first priority. But as you pointed out, there should be a throughput
> measurement, to see if this thing is really *useful* under certain overhead.
> 
> ----------
> Best regards,
> Wen