On 2 Apr 2010, at 18:08, Dan Wing wrote: -----Original Message----- >> From: Sabahattin Gucukoglu [mailto:mail@xxxxxxxxxxxxxxxxxxxxxxxx] >> Sent: Friday, April 02, 2010 9:48 AM >> To: Dan Wing >> Cc: ietf@xxxxxxxx >> Subject: Re: NAT Traversal With ICMP Replies >> On 2 Apr 2010, at 17:18, Dan Wing wrote: >> -----Original Message----- >>>> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On >>>> Behalf Of Sabahattin Gucukoglu >>>> Sent: Wednesday, March 31, 2010 5:43 PM >>>> To: ietf@xxxxxxxx >>>> 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
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf