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: http://linux.die.net/man/7/raw: "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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
