Subject: RE: NAT Traversal With ICMP Replies

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Apr 2010 09:18:23 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sabahattin Gucukoglu
> Sent: Wednesday, March 31, 2010 5:43 PM
> To: [email-masked]
> Subject: NAT Traversal With ICMP Replies
> 
> http://samy.pl/pwnat/
> 
> The idea is that NATs let back ICMP replies and send them to 
> hosts behind them if they suspect them to be responses to 
> messages sent from those hosts.  So, by making the reply 
> fixed and having a server behind a NAT continuously sending 
> the ICMP query that would elicit it, a server can learn a 
> client's IP address, and thus begin communication without a 
> central rendezvous server.
>
> An interesting idea, for sure. 

Several drawbacks, though, including no provision for multiple
PWNAT devices behind the same NAT.  Varying the ICMP query 
address could resolve that, to some degree (modulo birthday 
collisions).

> It might not be super 
> efficient, and there's the question of whose network gets all 
> these ICMP messages. 

http://ws.arin.net/whois/?queryinput=3.0.0.0

> Are we using it anywhere already?

We = IETF?  No.

-d

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 2 Apr 2010 17:47:38 +0100

On 2 Apr 2010, at 17:18, Dan Wing wrote:
-----Original Message-----
> http://ws.arin.net/whois/?queryinput=3.0.0.0

Yes.  We could solve the worst of both problems by assigning a *small* IANA block and arranging a blackhole for it.  We only need to trigger NAT behaviour, and we get to control the ICMP payload that should be expected.  Hamachi has nicked the 5/8 assignment, for its own use, to avoid overlapping private spaces (they aren't routed, of course, it's just for the communicating nodes on the UDP-encapsulated, NAT-traversing network).

Although I'm absolutely no fan of NAT, I can't help thinking this little technique might just help some, considering the only alternative is peer-mediated communications.  It should even work for DSLite deployment since the NATs are upstream.

Cheers,
Sabahattin

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Apr 2010 10:08:09 -0700

> From: Sabahattin Gucukoglu [mailto:[email-masked]] 
> Sent: Friday, April 02, 2010 9:48 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: NAT Traversal With ICMP Replies
> 
> Yes.  We could solve the worst of both problems by assigning 
> a *small* IANA block and arranging a blackhole for it.  We 
> only need to trigger NAT behaviour, and we get to control the 
> ICMP payload that should be expected.  Hamachi has nicked the 
> 5/8 assignment, for its own use, to avoid overlapping private 
> spaces (they aren't routed, of course, it's just for the 
> communicating nodes on the UDP-encapsulated, NAT-traversing network).
> 
> Although I'm absolutely no fan of NAT, I can't help thinking 
> this little technique might just help some, considering the 
> only alternative is peer-mediated communications. 

Not sure what you mean by 'peer-mediated communications'.

> It should 
> even work for DSLite deployment since the NATs are upstream.

As written, pwnat won't work for a large shared NAT, because
all of the pwnat 'servers' are sending ICMP queries using
the same 3.3.3.3 address.  To make pwnat work in such an
environment, each pwnat 'server' would have to choose its
own, non-colliding IP address to send its ICMP queries to,
and the pwnat client would need to be told that IP address
(and also the pwnat's publicly-visible IP address).

-d

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 2 Apr 2010 23:38:19 +0100

On 2 Apr 2010, at 18:08, Dan Wing wrote:
-----Original Message-----
> Not sure what you mean by 'peer-mediated communications'.

Communications mediated by a peer, like STUN or TURN.  It should really be "Third-party peer-mediated communications".  It's nice to remove dependence on another peer is what I was trying to say.

> (and also the pwnat's publicly-visible IP address).

Of course, yes, sorry.  Friday-night brain flab.  Somehow I got the idea we had the entire ICMP packet payload, but of course we only have the headers.  Would unsolicited ICMP echo replies, containing payload, work?

Cheers,
Sabahattin

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Apr 2010 15:52:36 -0700

> Communications mediated by a peer, like STUN or TURN.  It 
> should really be "Third-party peer-mediated communications".  
> It's nice to remove dependence on another peer is what I was 
> trying to say.

I suppose.

In Real Life, though, there is usually some kind of rendezvous
server that is part of the game itself, the DHT to exchange
peer ID's and chunk information (e.g., BitTorrent) -- which
could run a STUN server.  As for TURN, well, that's only
needed when both peers are behind 'bad' NATs (address and
port dependent filtering/mapping), and I don't know if 
pwnat/chownat improve upon that situation; I doubt they
do (because the client doesn't know its public port 
number).

There are other ideas floating around for DS-Lite and carrier
NATs, as well, including draft-wing-softwire-port-control-protocol.

> Of course, yes, sorry.  Friday-night brain flab.  Somehow I 
> got the idea we had the entire ICMP packet payload, but of 
> course we only have the headers.  Would unsolicited ICMP echo 
> replies, containing payload, work?

Dunno, seems it would depend on how paranoid the NAT is.  I
could imagine a NAT might only expect an ICMP echo-reply from
the same IP address as the echo-request.  

But it is possible to send long ICMP "TTL Exceeded" messages, 
see Section 4.2.2.3 of RFC1812 and Section 4 of RFC4884 --
so more information can be stashed into pwnat's TTL Exceeded
message.

But I have been unable to engage with the author of pwnat
(doesn't reply to emails), and I sincerely doubt the IETF
would standardize this mechanism.  That combination has 
reduced my personal interest in pwnat.

-d