[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: Wen Yuzhong
Subject: Re: [GNUnet-developers] [Gsoc 2015] Project proposal on GNUnet-over-ICMP
Date: Fri, 20 Mar 2015 12:24:32 -0400

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,

2015-03-19 16:33 GMT-04:00 Christian Grothoff <address@hidden>:

I'd also like to know if either of you has done any proof-of-concept
study to see how to get an ICMP with payload (!) past NATs.  Outgoing
ICMP ECHO/PING requests are usually very easy.

The crux is what does it take for (a typical) NAT to let a PONG through.
 Can we send one or more with a modified payload?  How will NATs react
to getting multiple PONGs in "response" to a single PING? Do we need to
make sure the responding host does not send a PONG as well (giving you 2
replies and doubling bandwidth)?

Will NATs typically allow such "duplicates"? How many? For how long?
How does the NAT match the PONG to the PING (especially if the payload
doesn't match)?  Maybe a typical implementation only looks at only
certain bits of the payload which we can fake while hiding the real
payload in the rest?

Overall, given that we wouldn't have to deal with NAT port mapping, I
like the idea. But given that we'd want to send a PONG with different
payload than the PING, I worry about NATs dropping the PONGs. Or maybe
you're thinking about other ICMP message types, but then I worry about
where we can put how much payload per ICMP.

Regardless, if you can find some paper with a measurement study OR do
some minimal pcap-based measurement study yourself *before* really
starting on this, that would be important to make sure we implement an
*effective* method.

My 2 cents


On 03/19/2015 08:31 PM, DocMalloc wrote:
> Hi!
> My name is matthias and I am the gnunet developer with the strongest
> focus on the transport subsystem and therefore I would be the mentor for
> this project. I have CC'ed Christian (gnunet guru) to keep him notified
> about your idea...
> My first impression is useful so there is no general objection from my
> side against this idea.
> 1) So just as a start:
> Do you have coding experience, in particular with C and under Linux?
> What kind of software projects did you work before?
> This is just to prevent frustration ... your project would be integrated
> in the existing transport infrastructure, so you should be experienced
> in understanding existing code and to integrate your idea in an existing
> project.
> 2) Could you give me an idea how you plan to use ICMP to allow peers to
> communicate?
> What is your goal and what are your assumptions about the environment?
> How do you plan to use ICMP?
> How do you plan to implement it?
> Cheers,
> Matthias
> On Thu, 2015-03-19 at 12:20 -0500, Yuzhong Wen wrote:
>> Hi all,
>> My name is Yuzhong Wen and I’d like to participate with a project for
>> GNUNet at Gsoc.
>> So from the idea page I saw that GNUNet is going to implement multiple
>> transport services support, so my idea is to build a transport service
>> which is based on ICMP. Specifically, I want to build something like a
>> Ping-tunnel between 2 peers. This could be useful in the situation
>> that the firewall has blocked transport layer protocols (like a
>> firewall blocks most of the UDP and TCP connections using a white list
>> policy) and only allows ICMP packets to passthrough the gateway.
>> I just submitted the proposal, however I’m not sure if this idea is
>> viable in current GNUNet design since right now I’m still trying to
>> understand the architecutre of GNUNet. Is there a mentor that can give
>> me some advises on that? Thanks!
>> Here’s the link to my proposal, should be accessable by organization
>> members.
>> ———
>> Best regards,
>> Wen
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden

My Fantasyland

reply via email to

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