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.

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

Cheers,
Sabahattin

smime.p7s
Description: S/MIME cryptographic signature

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