I thought this would be of interest to IP masq developers. Forwarded message: > The first game using my NAT scheme is ready to go. > You can try it by picking up a copy of Dark Reign > e.g. at http://xxxx/(edited out) > then installing the 1.3.10 or later patch; that patch > is currently at > http://xxxx/(edited out) [Not sure if these are confidential releases, so i have ommited the urls] > For completeness' sake, here's another explanation of my > scheme for supporting peer-to-peer gaming through NATs. > - Dan > > IP Masquading under Linux, and possibly many NATs / packet screening > firewalls, allocate a new port for each new outgoing > (inside source adr, inside source port, outside dest adr, outside dest > port) > quad. This makes a great deal of sense for normal clients which are > only trying to access outside servers; only one outside host ever > communicates with any one inside (adr, port) pair. > > It becomes a problem when doing peer-to-peer networking, where > the clients of a particular outside server all want to talk directly > amongst themselves *on the same port used to communicate with the server*, > and some clients are behind a NAT / IP Masquerading host / packet screening > > firewall. > > This re-use of a port for communicating with an outside server and several > outside peers just isn't anticipated by IP Masquerading under Linux. > > Port screening firewalls, NAT's, and IP Masquerade already maintain > a pool of (outside (adr, port), inside (adr, port)) > tuples which are allowed to exchange traffic. > > All they have to do to support this scheme is to > allow multiple records with the same outside (adr, port). > > How hard would it be to add this ability to Masq? > > For those of you who want to know how the heck the > peers will know each others' addresses, here are the > gory details: > > I'm proposing a general scheme for peer-to-peer UDP-based games > to implement NAT and masquerading support. The goal of the > scheme is to allow a group of hosts to send packets to each > other, even if they are behind different NATs or masquerading hosts. > Security is more or less maintained in that the protocol > only requires the firewall to open up return paths from > hosts we have sent packets to. > I have already implemented this scheme, and verified that > it works for certain kinds of routers and firewalls. > (Anyone who wants to test this scheme, buy a copy of > Dark Reign, and get the 1.3 patch when it's ready later > this week.) > Here's how the hosts know where to send the packets: > > 1) There is a well-known server with a well-known port, not > behind any NAT or firewall. Its only purpose is to relay > the public and local addresses of all participants in a session > to each other. (A host's public address is the address/ UDP port pair > seen by the outside world; its local address is the pair it > thinks it has.) > > 2) To join the session, a new host sends its local address > to the well-known server. The server then stores the new > host's public address (from the UDP header) together with its > local address (embedded in the packet). > The list of all participants' public and local addresses are > then sent down to the new host. The new host notes its own public > address in the reply from the server. > > 3) The server sends the public and local address of the > new host to all existing participants. > > 4) The new host then sends a hello packet to both the public and > local addresses of each participant; likewise, the existing > participants all send hello packets to both the public and > local addresses of the new host. The packet contains > the sending host's public and local addresses. > These are analogous to TCP's SYN packet, and are retransmitted > periodically if no response is received (see below). > > 5) The act of sending a packet to the other participants > signals the firewall that a reply will be coming back along > the reverse path. It opens up a return path which just > reverses the source and destination address/ UDP port pairs. > This seems to be a common feature of many firewalls and > SOHO routers (e.g. the Cisco PIX). I don't know how > widespread it is. Is there any data on what firewalls > support this behavior? > > 6) For participants behind different firewalls / NATs / masquerading > hosts, one packet (the one sent to the peer's public address) > will make it through. For participants behind the same firewall / NAT / > masquerading host, the other packet (the one sent to the peer's > local address) will make it through. > For participants with two IP interfaces, one or the other packet > will make it through; it doesn't matter which. > > Incoming hello packets are matched against the list > of outstanding outgoing hello packets. If either the > public or local address matches, then the incoming > packet is accepted, *the address on its UDP header is > taken to be the preferred reply address*, a reply > is sent, and any further incoming hello packets > from that host only cause a repeat of the original reply. > > In any case, the interesting part of the protocol > for the purposes of this discussion are step 5, in > which the firewall / NAT / whatever opens up a symmetrical > return path, and step 6, where a reply is sent along the > symmetrical return path. (There are two possible > return paths for hosts behind firewalls / NATs / whatevers, > and we can't know which one is right, so we try both.) > > The question is- when do you decide you need to allocate another > port? Current masq code does this *for each new source / destination > address / port 4-tuple*. This hurts me pretty badly. I would rather > they do it *for each new local address/port pair*. That way there > is only one public address/port for each local address/port. > > I only ask that external traffic be allowed in *if* an internal > host has sent a packet to that address, and then *only* along > the exact symmetrical return path. As I mentioned above, > the Cisco PIX firewall has this exact behavior. > > To anyone who has read this far, I salute you :-) > > The questions raised here are central to the future of > peer-to-peer Internet games. If everyone moves to > pure client-server games, these questions will cease > to be interesting. However, for certain kinds of games, > and for small numbers of participants (n < 20), I think > that direct peer-to-peer gaming has significant advantages > in some cases. (For one thing, the load on the central well- > known server is very low, which makes it economical to run > compared to the heavy load on the server in a pure client-server > game. I'm definitely into cheap servers that volunteer ISPs > can run...) > > Dan Kegel > Senior Programmer > Activision > > (The above opinions are mine alone, and are not those of my employer.) > -- "Ask Bill why function code 9 [in QDOS and still in MS-DOS, more than ten years later] ends in a dollar sign. No one in the world knows that but me." - Gary Kildall, author of CP/M --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
