RE: NAT Traversal With ICMP Replies

> On 2 Apr 2010, at 18:08, Dan Wing wrote:
> -----Original Message-----
> > > From: Sabahattin Gucukoglu 
> > > [mailto:mail(_at_)sabahattin-gucukoglu(_dot_)com] 
> > > Sent: Friday, April 02, 2010 9:48 AM
> > > To: Dan Wing
> > > Cc: ietf(_at_)ietf(_dot_)org
> > > Subject: Re: NAT Traversal With ICMP Replies
> > > On 2 Apr 2010, at 17:18, Dan Wing wrote:
> > > -----Original Message-----
> > > > > From: ietf-bounces(_at_)ietf(_dot_)org 
> > > > > [mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
> > > > > Behalf Of Sabahattin Gucukoglu
> > > > > Sent: Wednesday, March 31, 2010 5:43 PM
> > > > > To: ietf(_at_)ietf(_dot_)org
> > > > > 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
> > > 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'.
> 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.

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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf