Inet95 Abstract
`
`http://sydney.edu.au/engineering/it/~bob/Inet95/Abstracts/018.html
`
`Abstract: 018
`Tracks: engineering/technology
`Author: YEOM, Heon
`Title: A transparent TCP/IP gateway to connect private networks to the Internet
`
`A transparent TCP/IP gateway to connect private networks to the INTERNET
`Heon Y. Yeom and Ilhwan Kim
`Educational and Research Computing Center
`Seoul National University
`Seoul, Korea 151-742
`(Tel) 82-2-880-5583 (Fax) 82-2-887-1858
`yeom@arirang.snu.ac.kr
`As the use of the INTERNET grows exponentially and the remaining IP address
`space is getting smaller and smaller, there arises a need to devise a way
`to connect small private networks without giving full Internet access.
`The problem we are facing now is provide internet connection to thousands of
`K12 schools in Korea as part of the Korean Education Network(KREN) without
`wasting valuable IP addresses.
`In the RFC 1597, it was suggested to reserve certain class C or class B address
`space and use it repeatedly in a private network.
`Since all we need for each K12 schools is a class C address, we can use the
`same class C address for all the K12 schools we want to connect and give them
`just one or two real IP address. Since we have less than 10,000 K12 schools
`in Korea, it would only require one class B address to cover all the K12
`schools.
`However, no clear method was suggested to provide Internet services to the
`network nodes inside the private network. Since the IP address of the inside
`network are fake, it can not be used to communicate with outside network sites
`which have real IP address.
` -------- a fake class C network
` ---------------- / .
` / \/ .
` / \ .
` | Network of |--------- a fake class C network
` INTERNET ------| Class B |--------- a fake class C network
` \ (real IP) / .
` \ / --------- a fake class C network
` ---------------- .
`
`There are two ways proposed to handle this problem which is the same as
`providing internet connection to the sites inside the firewall.
`One is proposed in [KOKO92] where the gateway machine has a server named
`sockd which handles the socket allocation and port binding for the sites
`inside the firewall. When the inside site wants a network connection, it
`would use Rconnect(), and Rbind() to get the socket from the server.
`From the outside, all the network connection is from and to the gateway
`machine. It would be perfect except that all the network programs the
`inner sites use would be changed so that the socket allocation would be
`from the server and not from the inner site itself.
`Another solution is to install proxy server for all the network services
`inner sites want to have: proxy telnet, proxy ftp, proxy gopher, etc.
`What we are proposing is a way to transparently map the packets from the
`inner site so that it looks like as if it was from the gateway.
`
`1 of 3
`
`12/31/2013 10:44 AM
`
`Google Ex. 1506, pg. 1
`
`

`
`Inet95 Abstract
`
`http://sydney.edu.au/engineering/it/~bob/Inet95/Abstracts/018.html
`
`By restricting the network services that need to be provided to the inner
`network, a simple mapping gateway could handle the translation as follows.
`Whenever an inner site I1 wants to make a TCP connection with outside host
`O2, it would send a request as if it is on a real IP network.
`The gateway G which has a real IP address G, when receiving the packet,
`would make an entry of the ((I1,p1),(O2,p2)) with a port of its own (G,p3).
`From that point on,
`all the packets with originator (I1,p1) and destination (O2,p2) would be
`transformed into a packet with originator (G,p3) and sent to the outside
`network. Likewise, all the packets from the outside network with
`originator (O2,p2) and destination (G,p3) would be transformed with
`destination (I1,p1) and feed into the inner network.
`Using this method, all the network services requested by the inner network
`site can be serviced if it only requires simple TCP connection.
`One significant problem with this approach is that it can not handle the
`FTP data connection. As identified in [CHBE94], FTP data connection is
`originated from the FTP server after the client sends a port number it will
`listen to. When the FTP server sends a connection request to that port,
`the gateway would have no idea where this particular packet should be sent.
`There are two solutions to this problem. One is to change the FTP client
`so that it will initiate the data connection using the PASSIVE command of
`the FTP client. Another is for the gateway to intercept FTP PORT command
`PORT I1,p4 and allocate another gateway port for it so that PORT I1,p4
`would be transformed into PORT G,p5. Another solution would be to use the
`proxy FTP program on the gateway. It would depend on what the gateway
`machine can do. If it's a full blown UNIX machine, it would be easier to
`use the proxy FTP. On the other hand, if it is just a PC with two ethernet
`connections looking at the packets, the second solution would be better.
`We believe that the cases where the inner network site acts as the network
`service host would be very rare. However, we can still provide limited
`service so that each well known service would be provided by one or few
`servers in one private network. The number of servers is restricted by
`the number of real IP addresses assigned to the inner network.
`As for the UDP services, since there is no clear indication for the
`beginning and end of the UDP connection, it would be very difficult to do
`port allocation and transformation. However, the only UDP service we can
`think of that might be needed for this kind of environment is DNS service.
`It can be handled by having a DNS server in the inner network with real
`IP and change the named server so that it will resolve all the DNS query
`without DNS query forwarding.
`We have outlined a simple interconnection method to connect private network
`with fake IP to the Internet. This solution is only temporary fix and we
`hope that the next generation IP would have enough address space for all
`the people in the world.
`
`Appendix
`A. pseudo code for fake IP gateway
`main()
`{
`
`do {
`
`packet = get_next_packet();
`if (packet is from inner network) {
`newpacket = i_to_o(packet);
`send_packet(newpacket, outer interface);
`} else {
`newpacket = o_to_i(packet);
`send_packet(newpacket, inner interface);
`
`}
`
`2 of 3
`
`12/31/2013 10:44 AM
`
`Google Ex. 1506, pg. 2
`
`

`
`Inet95 Abstract
`
`http://sydney.edu.au/engineering/it/~bob/Inet95/Abstracts/018.html
`
`}
`
`} i
`
`_to_o(packet)
`{
`if (packet.flag == SYN) {
`alloc_port(packet);
`
`} n
`
`ewpacket.src_ip = gateway_ip;
`newpacket.src_port = get_gatewayport(packet.src_ip, packet.src_port);
`/* we should carefully design an algorithm to handle
`graceful shutdown of TCP connection..TBD */
`if ((packet.flag == FIN) || (packet.flag == RST)) {
`prepare_release_port(packet);
`f (packet.flag == ACK) {
`if (the packet is ACK to previous FIN..etc) {
`......
`release port w.r.t. packet flags;
`
`}i
`
`}
`
`} r
`
`eturn newpacket;
`
`} o
`
`_to_i(packet)
`{
`if (port_table[packet.dst_port] == NULL) {
`/* no entry in table, which means there is no TCP client
` in inner network, so send back reset to source */
`newpacket.dst_ip = packet.src_ip;
`newpacket.dst_port = packet.src_port;
`newpacket.src_ip = packet.dst_ip;
`newpacket.src_port = packet.dst_port;
`newpacket.flag |= RST;
`return newpacket;
`
`} n
`
`ewpacket.dst_ip = port_table[packet.dst_port].inner_ip;
`newpacket.dst_port = port_table[packet.dst_port].inner_port;
`/* again, we should redesign following algorithm to handle
`graceful close of TCP connection */
`if ((packet.flag == FIN) || (packet.flag == RST)) {
`prepare_release_port(packet);
`
`} r
`
`eturn newpacket;
`
`} R
`
`eferences
`[REKH94] Y.Rekhter, B.Moskowitz, "Address Allocation for Private Internets,
` RFC1597", Mar. 1994.
`[KOKO92] D. Koblas, M.R. Koblas,"SOCKS", USENIX Security Proceedings, III,
` Sep. 1992.
`[CHBE94] W.R. Cheswick, S.M. Bellovin, "Firewall and Internet Security",
` Addison Wesley, 1994.
`[PORE85] J. Postel, J. Reynolds, "File Transfer Protocol, RFC959",
` Oct. 1985.
`
`3 of 3
`
`12/31/2013 10:44 AM
`
`Google Ex. 1506, pg. 3