[Top][All Lists]

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

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

From: DocMalloc
Subject: Re: [GNUnet-developers] [Gsoc 2015] Project proposal on GNUnet-over-ICMP
Date: Sat, 21 Mar 2015 08:59:02 +0100

I think this approach requires a careful thinking about what the
envisioned environment is and what it tries to solve.

So I think we can distinguish between a packet filters restricting
traffic and a NAT devices. And in addition if none, 1 or both is
affected by such a device.

The goal is to achieve bi-directional, ICMP based communication. 

With NAT the challenge is to establish a mapping to allow the nat'ed
peer to receive data without having the NAT drop it. 

Here we need a careful evaluation what the behavior of current
implementations is.

Therefore a protocol sketch would be great to have...

On Fri, 2015-03-20 at 19:11 +0100, Christian Grothoff wrote:
> 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.

In the case that a peer tries to send ICMP-ECHO requests to a nat'ed
peer? Here ACK ... since the nat mapping is not established. If the
nat'ed peer previously established the mapping the non nat'ed peer could
send data using ECHO-replies. 

So there is a way required to keep the mapping established ... and we
need to evaluate how nat implementations treat the state (e.g. if they
dismiss a ECHO request mapping upon arrival of the first ECHO
response) ...

> 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.

Just a as starter question. Did you consider: 

"An IPPROTO_RAW socket is send only. If you really want to receive all
IP packets, use a packet(7) socket with the ETH_P_IP protocol. Note that
packet sockets don't reassemble IP fragments, unlike raw sockets. "

> > 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
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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