home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / sockd.zip / sockd.HLP (.txt) < prev    next >
OS/2 Help File  |  1998-08-15  |  66KB  |  1,848 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. SockD description ΓòÉΓòÉΓòÉ
  3.  
  4.  The multi-threaded socks server for OS/2 enables to build a firewall gateway 
  5. on an OS/2 (Warp) system. The objective is just to interconnect small TCP/IP 
  6. Lan with the public network (through a "Service Provider"). 
  7.  
  8.  Like in all "standard" sockd server, the protection is build in a 
  9. configuration file (sockd.cfg in the ETC directory). 
  10.  
  11.  Access is controlled with two statements "deny" or "permit". Origin address 
  12. and subnet mask and destination address and mask can be checked for a 
  13. destination port number... 
  14.  
  15. For applications using socks version 4 protocol the support  is only for TCP 
  16. application due to the protocol stack. 
  17.  
  18.  The current version has support for three LAN adapters (LAN0, LAN1 and LAN2), 
  19. and two SLIP or PPP adapters (sl0, sl1, ppp0 and ppp1). One of the "serial" 
  20. adapters can be configured in "auto-dial" to give access to the Internet 
  21. through a "network" provider. 
  22.  
  23.  The current version supports SOCKS Version 4 and 5. In SOCKS version 5, only 
  24. NO AUTHENTICATION REQUIRED and USERNAME/PASSWORD authentication methods are 
  25. supported. The GSSAPI support is NOT implemented. 
  26.  
  27.  In V5 only support for IP V4 addresses is provided not V6.  DNS names are 
  28. evidendly supported. 
  29.  
  30.  To be used, a correct support of the TCP/IP names must be implemented in  the 
  31. way the "client" stations can convert external names in IP addresses.  This 
  32. restriction can be modified with SOCKS Version 5 where DNS names have  to be 
  33. resolved only on the SOCKD station. 
  34.  
  35.  To provide the correct "names" support in Socks V4, we use the DNS kit of 
  36. TCP/IP V2.0  on the same workstation as "sockD". In this way this "nameD" 
  37. server can provide  caching mechanism to the external (and internal) name 
  38. servers.  We used also the DDNS kit of Warp Server in a similar configuration. 
  39.  
  40.  In Socks V5, only a resolv file pointing to a "public" name server and an 
  41. "hosts" file to traduce "internal" names are required. The usage of a real 
  42. "caching" name server is NOT mandatory. The customization of the "SockD" server 
  43. is easier. 
  44.  
  45. The support of UDP associated of V5 is a little bit modified to add support for 
  46. a "remote" ping command when the destination port is "1". In this case sockd 
  47. opens a "raw" socket with protocol "icmp" to ping the external host and 
  48. communicates with the standard UDP Associated protocol to the "client" host. 
  49.  
  50.  
  51. ΓòÉΓòÉΓòÉ 2. Auto-dial facility. ΓòÉΓòÉΓòÉ
  52.  
  53. You need to customize first the access to your network provider. 
  54.  
  55. SockD was only tested with IBM Global Network. When the access is working with 
  56. the "dialer.exe", you have to customize two "cmd" files one to get the access 
  57. and the second one to close it. 
  58.  
  59. This facility is only supported on one adapter sl0, sl1, ppp0 or ppp1. It was 
  60. only tested on sl0. 
  61.  
  62. To check if the connection is OK, sockd uses the "flags" of the adapter status. 
  63. When the sl0 adapter is "<UP,POINTTOPOINT>", the flags are "811" or 
  64. "<UP,POINTTOPOINT,RUNNING>" ("851")... 
  65.  
  66. Sockd reads normally a sockd.cfg and sockd.rte files in the ETC directory. 
  67. These files are the socks configuration. In auto-dial mode, sockd tries to 
  68. build an "automatic" config. It should be OK for the first tests. If you want 
  69. to look at this default config, you have just to read the sockd.log file (in 
  70. the sockd directory) after stopping sockd. 
  71.  
  72. By sample I used this sockdial.cmd whith a correct userid/password and account 
  73. to start the connection. 
  74.  
  75. /************************************************/
  76. /*                                              */
  77. /* sockdial.cmd :  to start the slip connection */
  78. /*                                              */
  79. /************************************************/
  80. 'start dialer account userid password -d'
  81.  
  82. And this sockclos.cmd to stop the connection after the "delay" without session 
  83. is expired. 
  84.  
  85. /***********************************************/
  86. /*                                             */
  87. /* sockclos.cmd :  to stop the slip connection */
  88. /*                                             */
  89. /***********************************************/
  90. 'dialer -c'
  91.  
  92. These two cmd MUST be put in a subdirectory in the PATH statement (I used 
  93. \TCPIP\BIN). 
  94.  
  95. Evidendly you have to enable the "auto-dial" function through the "dial-up" 
  96. option of the "config" menu (and setup your command names and the "delay" 
  97. time). Then you have to stop/start sockd. 
  98.  
  99. An other method consists in starting directly sockd with a parameter: 
  100.  
  101.   start sockd -dsl0
  102.  
  103.   where:  sl0  is the auto-dial adapter
  104.  
  105. In this case you have to keep the default for other parameters: "sockdial.cmd", 
  106. "sockclos.cmd" and 5 minutes of delay. 
  107.  
  108. The delay time should be shorter than the "delay" set in the "dialer" 
  109. configuration to keep the control of the connection in "sockd". 
  110.  
  111.  
  112. ΓòÉΓòÉΓòÉ 3. sockd.cfg ΓòÉΓòÉΓòÉ
  113.  
  114.  The configuration files are saved in the ETC directory. 
  115.  
  116. deny   0.0.0.0 0.0.0.0 9.0.0.0 255.0.0.0 gt 0
  117. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 ge 1024
  118. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 21
  119. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 20
  120. permit *=PhilG,Test 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 23
  121. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 70
  122. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 80
  123.  
  124.  A list of userids can be used in addition of IP addresses on the "permit" 
  125. statement. They are case sensitive. The value sent from the OS/2 Warp station 
  126. comes from the USER variable set in the "config.sys" in SOCKS V4. 
  127.  
  128.  On the time being no checking of "password" is performed (through identd). 
  129.  
  130. In SOCKS V5, the userid used in userid/password authentication is checked with 
  131. the userid list in the permit statement if *= field is set. 
  132.  
  133.  Good practice specifies a first statement to denies all external accesses to 
  134. your "private" network (all ports) with: 
  135.  
  136.  "deny 0.0.0.0 0.0.0.0 nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm gt 0"  where nnn is your 
  137. network number and mmm the mask. 
  138.  
  139.  then you can permit all stations from your network to access all TCP 
  140. applications through the socks gateway with: 
  141.  
  142. "permit nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm 0.0.0.0 0.0.0.0 gt 0" 
  143.  
  144. "proxy" statements can be added if you require to interconnect sockd servers. 
  145. The syntax is like : "proxy  IP_addr  port_nb  subnet_nb  subnet_mask auth comp 
  146. encr name [site_certificate] " 
  147. Where : 
  148.  IP_addr is the IP address of next proxy server 
  149.  port_nb is the port number (1080 by default) of this proxy server 
  150.  subnet_nb is the destination subnet number we can access through this proxy 
  151.  subnet_mask the destination subnet mask 
  152.  auth Y_or_N use local_node_name/node_name as userid/password authentication 
  153.  comp Y_or_N compress data frames on this proxy connection 
  154.  encr Y_or_N encrypt data frames on this proxy connection 
  155.  name remote node name (used as password in userid/pswd authentication) 
  156.  site_certificate a pgp public key ring where we can get the key for node name 
  157.  
  158.  
  159. ΓòÉΓòÉΓòÉ 4. sockd.pro ΓòÉΓòÉΓòÉ
  160.  
  161.  
  162.  SOCKD uses also a profile file (sockd.pro) in the ETC directory to save the 
  163. number of sessions set, server port nb, the window position, the level of 
  164. logging used ("Full", "all Sessions", "only errors and sessions refused 
  165. (Minimum)" or "No logging") and the font used on main window. 
  166.  
  167.  In the second line of this file, we have the "auto dial" parameters:  is this 
  168. facility enabled (Y or N), the dial command, the hangup command,  and the 
  169. "short hold mode" delay. 
  170.  
  171.  In addition a "TCP" time-out and a "UDP" time-out (in seconds) are  also set. 
  172. These permit to "tune" the delay sockd is waiting for the next  transaction 
  173. before considering the session is lost.  If these parameters are too short 
  174. sockd is cutting the session during a  normal "wait" time. If they are too 
  175. long, some "client" threads can be  blocked and are not available for "new" 
  176. sessions. 
  177.  
  178.  The defaults are respectively 20 minutes for TCP and 50 seconds for UDP 
  179. applications. TCP is really using a "session". In UDP there is no real 
  180. session. The communication is never really closed. The UDP time-out is used  to 
  181. standardly close this communication. SockD was tested with Real-Audio  UDP 
  182. application and archie as UDP associate applications. The default of  50 
  183. seconds was enough to use both applications with a dial-up connection.  The 
  184. default of 20 minutes for TCP applications was set bigger than the  standard 
  185. FTP time-out (15 minutes). It is NOT enough for "permanent"  telnet sessions. 
  186.  
  187. To complete these time-out values, the session setup time-out can also be 
  188. customized. Its default value is two minutes (120 seconds). The valid values 
  189. are between 1 and 30 minutes given in second (60 to 1800). 
  190.  
  191. A third line contains info on log archiving : yes or no, delay in hours or 
  192. days, delay value, maximum number of files to archive. The fifth parm in this 
  193. line permits to support only socks V5 userid/password authentication if a 
  194. userid is set on a permit statement. In Socks V4 there is no password checking. 
  195. Normally sockd is giving the same process to V4 as V5. Enabling this option 
  196. obliges to use a password in addition to the userid. The latest keyword on this 
  197. third line defines if the encryption is required on proxy connections otherwise 
  198. the permission is only checked with authenticaton and with the "permit" by 
  199. addresses given in the sockd.cfg file. 
  200.  
  201. A fourth line can be added with the local node name. If this parameter exists 
  202. it can be used for a sort of userid/password checking on proxy connections. The 
  203. name is case sensitive with a maximal length of 128 characters. No space, new 
  204. line or carriage return can be used in it. A second parameter can be set as a 
  205. PGP certificate file name. When encryption should be supported we 'll find the 
  206. private key in it corresponding to the local node name as userid. 
  207.  
  208.  This file is created automatically by sockd.exe but you can complete it 
  209. through the "profile" menu option. 
  210.  
  211.  
  212. ΓòÉΓòÉΓòÉ 5. sockd.rte ΓòÉΓòÉΓòÉ
  213.  
  214.  
  215.  Another configuration file (sockd.rte) is required for SOCKS_BIND in the ETC 
  216. directory describing the gateway adapters and IP addresses. Most of the 
  217. applications (Web Explorer, Rtelnet, ...) use only SOCKS_CONNECT. That's the 
  218. reason why I put "sockd.rte" as optional.... But if you want to use Rftp you 
  219. need the SOCKS_BIND support and then sockd.rte. 
  220.  
  221.  It is a list of the local adapter addresses and the neworks you can reach 
  222. through these... These definitions are used in sequence for testing an address. 
  223. Thus it seems better to put the more restrictive definitions first (describing 
  224. private network access) and the "public network" adapter finally (giving access 
  225. to world). 
  226.  
  227.  By sample : 
  228.  
  229. 9.36.69.41    9.36.69.32 255.255.255.224
  230. 9.132.89.238  0.0.0.0    0.0.0.0
  231.  
  232. If you plan to use the auto-dial facility avoid to set routing for the dial-up 
  233. adapter. If no route file is found, sockd builds one with your LAN adapters 
  234. giving access to their local subnets and put a last dynamic entry for the 
  235. switched adapter giving access to world (0.0.0.0). 
  236.  
  237. You can want to have other subnets accessible through fixed (LAN) adapters. For 
  238. that you must define a sockd.rte with a line per subnet and setting in first 
  239. parameter the local IP address giving access to it. Sockd 'll add dynamically a 
  240. last entry for the switched adapter giving access to 0.0.0.0 
  241.  
  242.  By sample : 
  243.  
  244. 9.36.71.9     9.36.71.0   255.255.255.0
  245. 9.132.89.238  9.0.0.0     255.0.0.0
  246. 9.132.89.238  198.74.69.0 255.255.255.0
  247.  
  248.  
  249. ΓòÉΓòÉΓòÉ 6. sockd.usr ΓòÉΓòÉΓòÉ
  250.  
  251.  
  252. This file is in the ETC directory  for Socks version 5 userid/password 
  253. authentication. On the time being, no encryption technic is used on this 
  254. confidential dataset. A userid as a password can theoretically use 256 
  255. characters. I think in our test implementation it is limited to 255 (due to the 
  256. end of string character). 
  257.  
  258.  By sample : 
  259.  
  260. userid01 password01
  261. userid02 password02
  262.  
  263.  
  264. ΓòÉΓòÉΓòÉ 7. Utilisation: ΓòÉΓòÉΓòÉ
  265.  
  266.  
  267.  Start sockd without any parameter or with some of these options: 
  268.  
  269.      "-c" option: The number of concurrent clients is 32 by default. It can be 
  270.       changed at startup with the -c parameter or by modifying the sockd.pro 
  271.       profile file with the menu option. By sample :"sockd -c32" to support 32 
  272.       simultaneous clients. Note there is NO space between -c and the value. 
  273.       This number should be between 8 and 510. If this number is higher than 60 
  274.       but lower than 201, it is rounded to the next multiple of 5. If it is 
  275.       between 200 and 510 it is rounded to the next multiple of 10. Each client 
  276.       uses one thread (in addition to the base sockd thread). You must check 
  277.       the "THREADS" keyword in the CONFIG.SYS to be able to support what your 
  278.       sockd configuration requires. The minimum you must set for sockd is the 
  279.       number of concurrent sessions plus four (for some other threads). In OS/2 
  280.       Warp V4, the default is 64 and the maximum is 4096. Very often the system 
  281.       is customized with THREADS=1024 which is correct for all sockd config. 
  282.  
  283.      "-l" option: to suppress logging (sockd.log file in the current 
  284.       directory) 
  285.  
  286.      "-i" option: to start iconized . 
  287.  
  288.      "-d" option: to setup an auto-dial adapter, by sample "-dsl0". 
  289.  
  290.      "-p" option: by default sockd uses the port 1080. You can change it 
  291.       starting "sockd -p2080" by sample. 
  292.  
  293.   If you want to use more than one option, specify different parameters: "start 
  294.  sockd -c48 -p2080 -i". 
  295.  
  296.   The frame forwarding MUST be disabled (with the "ipgate off" command or 
  297.  through MPTS customization) to protect the access to your "internal" network. 
  298.  
  299.   A "socks" support is required on client stations to use applications through 
  300.  this gateway or a Web Browser with "socks" support. 
  301.  
  302.  
  303. ΓòÉΓòÉΓòÉ 8. SOCKD menu ΓòÉΓòÉΓòÉ
  304.  
  305.      "Config": create, modify or simply check your configuration 
  306.  
  307.         -  "edit": to create or modify "line by line" the sockd.cfg in ETC 
  308.            directory 
  309.  
  310.         -  "proxy": to define proxy servers and the subnets they are giving 
  311.            access. 
  312.  
  313.         -  "view": to review the configuration in memory and eventualy change 
  314.            it    with the standard MLE (Multiple Line Entry field) keyboard 
  315.            manipulation.    (select text with mouse button 1 or Shift key and 
  316.            move the cursor,    then cut, copy and paste text with Ctrl+Delete, 
  317.            Shift+Delete and Shift+Insert) 
  318.  
  319.         -  "profile": to change the maximum number of concurrent sessions, 
  320.            the server port number or the logging level. 
  321.  
  322.         -  "route": to configure the sockd.rte file in ETC directory. 
  323.  
  324.         -  "save conf": to save the sockd.cfg from memory to ETC directory 
  325.  
  326.         -  "userid": for Socks V5 Userid/Password authentication method 
  327.  
  328.         -  "dial-up": to customize auto-dial facility 
  329.  
  330.         -  "font": to select the font used in the main window. 
  331.  
  332.      "reset": If you want to activate a change, a new profile or config 
  333.  
  334.         -  "server": to stop/restart the server 
  335.  
  336.         -  "log file": to clean the log file when reports are too long. 
  337.  
  338.      "Report": 
  339.  
  340.         -  "accepted": to check all sessions through this server 
  341.  
  342.         -  "denied": to check all demands rejected by the server. 
  343.  
  344.         -  "connect": to read the dial-up connection time in auto-dial mode. 
  345.  
  346.      "Help": to read this help file. 
  347.  
  348.      "Exit": to save the "profile" file and exit. 
  349.  
  350.  
  351. ΓòÉΓòÉΓòÉ 9. DNS support ΓòÉΓòÉΓòÉ
  352.  
  353.  
  354. ΓòÉΓòÉΓòÉ 9.1. How to setup a Name server ΓòÉΓòÉΓòÉ
  355.  
  356.  
  357.  To solve the V4 "name" problem, I put the DNS kit (at CSD UN60004 level) on 
  358. the PS/VP. This name server should be customized with caching to the external 
  359. name server(s) and to internal domain name server. On the "client" station the 
  360. resolv2 file points to the socks gateway address as the name server (the DNS 
  361. running on the sockd station can be the only name server on this small subnet). 
  362.  
  363.  Here after the configuration files used during our tests, where: 
  364.  
  365.      Where test.benelux.ibm.com (9.36.71.0) is the 'private' domain 
  366.  
  367.      ztmaixn1.benelux.ibm.com (9.132.56.2) is the external name server for the 
  368.       ibm.com domain and ns01.ny.us.ibm.net (165.87.194.244) is the external 
  369.       DNS server. 
  370.  
  371.      The socks gateway is using 9.132.89.238 on the "ibm.com" adapter and 
  372.       9.36.71.9 on the "secure" side (philg.benelux.ibm.com). 
  373.  
  374.      Tests were performed from testuser.test.benelux.ibm.com (9.36.71.10). 
  375.  
  376.      All "external" sessions were performed through the sl0 adapter and a 
  377.       connection to IBM Global Network as "Service" provider. 
  378.  
  379.  In fact, on a small LAN with just a few PCs connected a "hosts" file must be 
  380.  enough to succeed with DNS conversion in Socks V5. 
  381.  
  382.   hosts file in ETC directory
  383.  
  384.   9.132.89.238      bedb238.benelux.ibm.com
  385.   9.36.71.9         bedb238.philg.benelux.ibm.com
  386.   9.36.71.10        testuser.philg.benelux.ibm.com
  387.   165.87.194.244    ns01.ny.us.ibm.net
  388.   128.123.35.151    hobbes.nmsu.edu
  389.   206.101.97.101    www.lycos.com
  390.   205.216.146.70    www.yahoo.com
  391.  
  392.  In Socks V4, you can perform the first sockd tests just with a similar hosts 
  393.  file. But quickly, you should be blocked and due to the protocol you need to 
  394.  start a "named" server on your sockd gateway. You need then a "resolv2" file 
  395.  on your LAN attached PC pointing to your named server. 
  396.  
  397.  In any case keep also an "hosts" file on your sockd PC, because the code uses 
  398.  a "gethostbyaddr()" macro to get the "hostname" of the workstation. Sometimes 
  399.  the named server doesn't answer and you have to start sockd before named. You 
  400.  need then the "hosts" file to get a name. 
  401.  
  402.  
  403. ΓòÉΓòÉΓòÉ 9.2. DNS Kit of TCP/IP V2 ΓòÉΓòÉΓòÉ
  404.  
  405.  named.bt 
  406.  
  407. ;
  408. ; NAMED.BT file for name server configuration.
  409. ;
  410. ; type       domain                      source file or host
  411. ;
  412. domain   philg.benelux.ibm.com
  413. cache    .                          d:\\tcpip\\etc\\namedb\\named.ca
  414. primary  philg.benelux.ibm.com      d:\\tcpip\\etc\\namedb\\named.dom
  415. primary  71.36.9.in-addr.arpa       d:\\tcpip\\etc\\namedb\\named.rev
  416. ;
  417. ;
  418. domain   benelux.ibm.com
  419. primary  ztmaixn1.benelux.ibm.com  9.132.56.2
  420. primary  9.in-addr.arpa            9.132.56.2
  421. ;
  422. domain   ibm.net
  423. primary  ns01.ny.us.ibm.net        165.87.194.244
  424. primary  .in-addr.arpa             165.87.194.244
  425. ;
  426.  
  427.  named.ca 
  428.  
  429. ;
  430. ; define parent(root) domain nameserver (Note trailing dot)
  431. ;
  432. philg.benelux.ibm.com.        99999999  IN  NS  bedb238.benelux.ibm.com.
  433. 71.36.9.in-addr.arpa.         99999999  IN  NS  bedb238.benelux.ibm.com.
  434. benelux.ibm.com.              99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  435. ibm.com.                      99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  436. 9.                            99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  437. 9.in-addr.arpa.               99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  438. in-addr.arpa.                 99999999  IN  NS  ns01.ny.us.net.com.
  439. ;
  440. ; address of domain nameservers
  441. ;
  442. bedb238.philg.benelux.ibm.com.  99999999  IN  A   9.36.71.9
  443. bedb238.benelux.ibm.com.        99999999  IN  A   9.132.89.238
  444. ztmaixn1.benelux.ibm.com.       99999999  IN  A   9.132.56.2
  445. beda002.benelux.ibm.com.        99999999  IN  A   9.132.88.2
  446. ns01.ny.us.net.com.             99999999  IN  A   165.87.194.244
  447. ;
  448.  
  449. Where ns01.ny.us.net.com is the name server of the Internet provider... 
  450.  
  451.  named.dom 
  452.  
  453. ;
  454. ;********************************
  455. ;*  Start of Authority Records  *
  456. ;********************************
  457. ;
  458. @ IN SOA  bedb238.philg.benelux.ibm.com.   (
  459.         93052601 ; Serial number for this data (yymmdd##)
  460.         86400    ; Refresh value for secondary name servers
  461.         300      ; Retry value for secondary name servers
  462.         864000   ; Expire value for secondary name servers
  463.         3600 )   ; Minimum TTL value
  464. ;
  465. @      IN  NS   bedb238.philg.benelux.ibm.com.
  466. ibm.com.   IN  NS   bedb238.philg.benelux.ibm.com.
  467. ibm.com.   IN  NS   ztmaixn1.benelux.ibm.com.
  468. com.   IN  NS   bedb238.philg.benelux.ibm.com.
  469. com.   IN  NS   ns01.ny.us.ibm.net
  470. edu.   IN  NS   ns01.ny.us.ibm.net
  471. be.    IN  NS   ns01.ny.us.ibm.net
  472. ;
  473. ;********************************
  474. ;*  Domain Address Information  *
  475. ;********************************
  476. ;
  477. bedb238                    86400  IN  A      9.36.71.9
  478.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  479. ;
  480. testuser                   86400  IN  A      9.36.71.10
  481.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  482. ;
  483. bedb238.benelux.ibm.com.   86400  IN  A      9.132.89.238
  484. bedb237.benelux.ibm.com.   86400  IN  A      9.132.89.237
  485. ns01.ny.us.ibm.net         86400  IN  A      165.87.194.244
  486. ztmaixn1.benelux.ibm.com   86400  IN  A      9.132.56.2
  487. w3.almaden.ibm.com.        86400  IN  A      129.33.24.62
  488. w3.pe.au.ibm.com.          86400  IN  A      9.8.32.2
  489. w3.austin.ibm.com.         86400  IN  A      9.3.246.8
  490. w3.bocaraton.ibm.com.      86400  IN  A      9.83.4.179
  491. w3.portsmouth.uk.ibm.com.  86400  IN  A      9.180.145.185
  492. w3.hursley.ibm.com.        86400  IN  A      9.20.2.34
  493. w3.issc.ibm.com.           86400  IN  A      9.242.89.217
  494. isscw3.raleigh.ibm.com.    86400  IN  A      9.67.1.114
  495. w3nhd.raleigh.ibm.com.     86400  IN  A      9.67.195.102
  496. netstd.raleigh.ibm.com.    86400  IN  A      9.67.1.114
  497. w3.raleigh.ibm.com.        86400  IN  A      9.67.4.22
  498. www.tcp.raleigh.ibm.com.   86400  IN  A      9.67.106.6
  499. www.lycos.com.             86400  IN  A      206.101.97.101
  500. www.yahoo.com.             86400  IN  A      205.216.146.70
  501.  
  502. The translation of www.lycos.com, www.yahoo.com, ... Are there to have a method 
  503. to start a dial-up connection without the external DNS server. These name 
  504. translations are required for Socks V4 auto-dial process... 
  505.  
  506. You must setup there the addresses of the WWW servers set in the quicklist of 
  507. the end-users connected on the local LAN while Web explorer is not supporting 
  508. V5. 
  509.  
  510.  named.rev 
  511.  
  512. ;
  513. ;********************************
  514. ;*  Start of Authority Records  *
  515. ;********************************
  516. ;
  517. 71.36.9.in-addr.arpa. IN  SOA   bedb238.philg.benelux.ibm.com. (
  518.         93052601 ; Serial number for this data (yymmdd##)
  519.         86400    ; Refresh value for secondary name servers
  520.         300      ; Retry value for secondary name servers
  521.         864000   ; Expire value for secondary name servers
  522.         3600 )   ; Minimum TTL value
  523.  
  524. 71.36.9.in-addr.arpa.  IN  NS   bedb238.philg.benelux.ibm.com.
  525. ;
  526. 9              IN  PTR   bedb238.philg.benelux.ibm.com.
  527. 10             IN  PTR   testuser.philg.benelux.ibm.com.
  528. 237.89.132.9.in-addr.arpa.  IN  PTR   bedb237.benelux.ibm.com.
  529. 238.89.132.9.in-addr.arpa.  IN  PTR   bedb238.benelux.ibm.com.
  530. 101.97.101.206.in-addr.arpa.  IN  PTR  www.lycos.com.
  531. 70.146.216.205.in-addr.arpa.  IN  PTR  www.yahoo.com.
  532.  
  533. The translation of bedb238.benelux.ibm.com is required to start sockd when the 
  534. name server is running, because 9.132.89.238 is the IP address of the "lan0" 
  535. adapter. 
  536. SockD uses a "gethostbyaddr()" macro to get the host-name of the system where 
  537. it is running. If the name server can not give it, sockd is blocked during 
  538. start-up... 
  539.  
  540.  
  541. ΓòÉΓòÉΓòÉ 9.3. DDNS Kit of Warp server ΓòÉΓòÉΓòÉ
  542.  
  543. In the \MPTN\ETC\NAMEDB directory we used the following config files. 
  544.  
  545.  named.bt 
  546.  
  547. ;
  548. ; NAMED.BT file for name server configuration.
  549. ;
  550. ; type       domain                  source file or host
  551. ;
  552. domain   philg.benelux.ibm.com
  553. primary  philg.benelux.ibm.com c:\\mptn\\etc\\namedb\\named.dom presecured nokeytosec
  554. primary  71.36.9.in-addr.arpa  c:\\mptn\\etc\\namedb\\named.rev presecured nokeytosec
  555. ;
  556. ;
  557. cache    .              c:\\mptn\\etc\\namedb\\named.ca  presecured nokeytosec
  558. ;
  559.  
  560.  named.dom 
  561.  
  562. ;
  563. ;********************************
  564. ;*  Start of Authority Records  *
  565. ;********************************
  566. ;
  567. @   IN  SOA        bedb238.philg.benelux.ibm.com. (
  568.         96090101 ; Serial number for this data (yymmdd##)
  569.         86400    ; Refresh value for secondary name servers
  570.         300      ; Retry value for secondary name servers
  571.         864000   ; Expire value for secondary name servers
  572.         3600 )   ; Minimum TTL value
  573. ;
  574. @      IN  NS   bedb238.philg.benelux.ibm.com.
  575. ;
  576. ;********************************
  577. ;*  Domain Address Information  *
  578. ;********************************
  579. ;
  580. bedb238                    86400  IN  A      9.36.71.9
  581.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  582. ;
  583. testuser                   86400  IN  A      9.36.71.10
  584.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  585. ;
  586. ns01.ny.us.ibm.net         86400  IN  A      165.87.194.244
  587. www.lycos.com.             86400  IN  A      206.101.97.101
  588. www.yahoo.com.             86400  IN  A      205.216.146.70
  589.  
  590.  named.rev 
  591.  
  592. ;
  593. ;********************************
  594. ;*  Start of Authority Records  *
  595. ;********************************
  596. ;
  597. 71.36.9.in-addr.arpa. IN  SOA  bedb238.philg.benelux.ibm.com. (
  598.         93052601 ; Serial number for this data (yymmdd##)
  599.         86400    ; Refresh value for secondary name servers
  600.         300      ; Retry value for secondary name servers
  601.         864000   ; Expire value for secondary name servers
  602.         3600 )   ; Minimum TTL value
  603.  
  604. 71.36.9.in-addr.arpa.  IN  NS   bedb238.philg.benelux.ibm.com.
  605. ;
  606. 9.71.36.9.in-addr.arpa.       IN  PTR   bedb238.philg.benelux.ibm.com.
  607. 10.71.36.9.in-addr.arpa.      IN  PTR   testuser.philg.benelux.ibm.com.
  608. 101.97.101.206.in-addr.arpa.  IN  PTR   www.lycos.com.
  609. 70.146.216.205.in-addr.arpa.  IN  PTR   www.yahoo.com.
  610.  
  611.  named.ca 
  612.  
  613. ;
  614. ; define parent(root) domain nameserver (Note trailing dot)
  615. ;
  616. in-addr.arpa.           99999999  IN  NS  ns01.ny.us.net.com.
  617. ;
  618. ; address of domain nameservers
  619. ;
  620. ns01.ny.us.net.com.     99999999  IN  A   165.87.194.244
  621. ;
  622.  
  623.  
  624. ΓòÉΓòÉΓòÉ 9.4. resolv2 on SockD server ΓòÉΓòÉΓòÉ
  625.  
  626. domain philg.benelux.ibm.com
  627. nameserver 9.36.71.9
  628.  
  629.  
  630. ΓòÉΓòÉΓòÉ 9.5. resolv on SockD server ΓòÉΓòÉΓòÉ
  631.  
  632. domain philg.benelux.ibm.com
  633. nameserver 9.36.71.9
  634.  
  635.  
  636. ΓòÉΓòÉΓòÉ 9.6. resolv2 on end-user workstation ΓòÉΓòÉΓòÉ
  637.  
  638. domain philg.benelux.ibm.com
  639. nameserver 9.36.71.9
  640.  
  641.  
  642. ΓòÉΓòÉΓòÉ 9.7. Test configuration ΓòÉΓòÉΓòÉ
  643.  
  644.                  ----
  645.             ----     ---
  646.         ----            ----
  647.     ----    Internet        --
  648.        ----                    -
  649.            ------ IBM IGN   --
  650.                 ---*-------
  651.                    *
  652.                    *
  653.                 *******                     testuser
  654.                  *   *  Modem              ----------
  655.                   * *   Dial-up            *Thinkpad*
  656.                    *                       ----*-----
  657.       * *          *                           *
  658.     *     *  ------*------    Ethernet         *9.36.71.10
  659.    * T-R   *** PS/VP     *---------------------*---
  660.     *     *  * bebd238   *9.36.71.9
  661.       * *    -------------
  662.          9.132.89.238
  663.  ibm.com                          philg.benelux.ibm.com
  664.  9.0.0.0                             9.36.71.0
  665.  
  666. With a correct setup, it is possible to use Internal servers (ibm.com) without 
  667. dialing from "testuser". If an external server is used (by sample 
  668. www.yahoo.com) the auto-dial is automaticcally used. 
  669.  
  670. The choice is done through "sockd.rte" configuration. By default sockd gives 
  671. only access to the "local" subnet on the LAN adapter (9.132.88.0). 
  672.  
  673.  
  674. ΓòÉΓòÉΓòÉ 10. Proxy  support ΓòÉΓòÉΓòÉ
  675.  
  676.  A "proxy" socks server support is implemented. To use it you need to know the 
  677. IP address of the next sockd for OS/2 server and the subnets you can access 
  678. through this remote node. 
  679.  
  680.  From a LAN connected to Internet in "auto-dial" mode it is possible to access 
  681. servers located on an other LAN attached to Internet through a sockd using a 
  682. fixed IP address (mainly with a leased line). 
  683.  
  684.  You must "permit" the access on both sockd servers. Only the dial-up sockd has 
  685. to define the "leased line attached" sockd with a "proxy" statement. 
  686.  
  687. To setup a proxy  you must configure the connection on the remote site (the 
  688. site where the user's sessions are started pointing to "central site" servers). 
  689. The remote site can use an auto-dial sockd. You must define a "fixed" IP 
  690. address for the "central" site, but on the "central" sockd no definition is 
  691. required (except the permit statements) to accept remote proxies. 
  692.  
  693. In this way the Internet can be used to transport data between distributed 
  694. offices. You need a different subnet on each side (but it can be a "reusable" 
  695. nework address) and then you must build the "routing" with proxy statements. 
  696.  
  697. If you want a light authentication to validate the connection, you must define 
  698. a local node name in each sockd profile, and give the correct node name in the 
  699. proxy setup on the remote site. The connection between proxies uses socks V5 
  700. protocols and sockd uses the node names as userid/password for authentication. 
  701.  
  702. The use of PGP certificates is required to support encryption. In the "profile" 
  703. configuration (sockd.pro) you have to specify the "private" key ring for this 
  704. node and its node name. In the "proxy" setup window you must give the "public" 
  705. PGP key ring file for this "remote" node and its name. A button exists on the 
  706. window to extract the node name(s) from the PGP certificate. 
  707.  
  708. In the current version of SockD the node names are limited to 128 characters. 
  709. The node names can contain spaces or any special characters. They are case 
  710. sensitive. No hexa 0 value can be used. It can be a small sentence. For 
  711. encryption support sockd uses the PGP userids exactly as written in the PGP 
  712. certificates. That's why I set a button to read these userids from the PGP 
  713. certificate given by its file name in the proxy or profile setup window. 
  714.  
  715. To succeed with proxy encryption you must specify the corresponding PGP 
  716. certificate in the proxy statement of the remote sockd and in the profile of 
  717. the local sockd, thus the private certificate on one site and the public on the 
  718. other site. You must distribute the "public" certificates to the remote 
  719. sites... 
  720.  
  721. A first step consists in generating the pair of private and public certificates 
  722. with PGP and to rename secring.pgp and pubring.pgp to (by sample) thinkpad.sec 
  723. and thinkpad.pub or gateway.sec and gateway.pub. After you can copy these files 
  724. in the sockd directory locally(.sec) and remotely(.pub). 
  725.  
  726. An "authentication" frame is sent before each socks command and connection 
  727. initialization. This packet is set with local and remote node names (found as 
  728. userids in PGP certificates) and a 128 bits key. If the signature is accepted 
  729. all TCP data packets are encrypted. This 128 bits key is randomly calculated 
  730. for each socket connection... 
  731.  
  732. Only "Connect" and "Bind" sessions are encrypted. The UDP Associate sessions 
  733. are NOT encrypted or compressed. An option exists to define the proxy support 
  734. only for encrypted sessions requiring always the encrypted authentication and 
  735. data encryption ("encrypted sessions only"). This method permits a more secure 
  736. socks server. 
  737.  
  738. To test the proxy support I used my travelling thinkpad and defined as proxy a 
  739. fixed desktop PC giving access to Internet through a dial-up connection. Both 
  740. PCs were connected to our intranet LAN. I defined locally in the socks config 
  741. file the address 127.0.0.1 (the loopback adapter) as the socks gateway. When 
  742. sockd was started on the thinkpad it rerouted all sessions to the proxy giving 
  743. access to 0.0.0.0... 
  744.  
  745. Used configuration files : 
  746.  
  747.  sockd.pro 
  748.  
  749. 32 1080 380 270 400 300 win F Tms Rmn
  750. N sl0 sockdial.cmd sockclos.cmd 300 1200 50
  751. N D 1 7 N
  752. My_travelling_Thinkpad thinkpad.sec
  753.  
  754.  sockd.cfg 
  755.  
  756. deny 0.0.0.0 0.0.0.0 9.0.0.0 255.0.0.0 gt 0
  757. deny 0.0.0.0 0.0.0.0 127.0.0.0 255.0.0.0 gt 0
  758. permit 9.132.0.0 255.255.0.0 0.0.0.0 0.0.0.0 gt 0
  759. permit 127.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 gt 0
  760. proxy 9.132.89.237 1080 0.0.0.0 0.0.0.0 Y Y N  Gateway_to_the_Internet  gateway.pub
  761.  
  762.  sockd.rte 
  763.  
  764. 9.132.89.142 0.0.0.0 0.0.0.0
  765. 127.0.0.1  127.0.0.0 255.0.0.0
  766.  
  767.  socks.cfg 
  768.  
  769. direct 9.0.0.0 255.0.0.0
  770. sockd @=127.0.0.1 0.0.0.0 0.0.0.0
  771.  
  772.  
  773. ΓòÉΓòÉΓòÉ 11. Archiving sockd log files and reporting ΓòÉΓòÉΓòÉ
  774.  
  775.  Sockd can now archive its log files. The setup is done through the "profile" 
  776. option of the main window menu. Four parameters are saved in the third line of 
  777. the sockd.pro file in the ETC directory. The first parameter indicates if Yes 
  778. or No the option is selected. The second parameter is "H" for hours or "D" for 
  779. days. The third gives the delay used to close the sockd.log file and rename it 
  780. to "sockdlog.XXX" where XXX is a three digits number. The fourth indicates the 
  781. maximum number of archived files (+ the current sockd.log). 
  782.  
  783.  The default is to keep seven files and to archive every 24 hours. With this 
  784. setup you can build a weekly report using the sample REXX reporting program 
  785. "sockdrep.cmd" (just type "sockdrep" without parm in the directory sockd is 
  786. running)... 
  787.  
  788.  
  789. ΓòÉΓòÉΓòÉ 12. How to manage sockd from batch command files ΓòÉΓòÉΓòÉ
  790.  
  791.  An os/2 command called "sockdmsg" permits to reset the socks server 
  792. configuration from the sockd.cfg file in the ETC directory or from the 
  793. sockd.pro profile.. It is a method to get support for variable config depending 
  794. by sample of the time of the day. 
  795.  
  796. The sockdmsg module supports three types of requests: 
  797.  
  798.    1. "sockdmsg -c [sockd.cfg]" to change the socks server configuration.  It 
  799.       uses sockd.cfg from the ETC directory if no file name is given as second 
  800.       parameter. If a name is present, sockd looks for this file in the ETC 
  801.       directory  except if the file name includes some real path information (a 
  802.       backslash or  a colon). 
  803.  
  804.    2. "sockdmsg -p [sockd.pro]" to restart sockd from a profile file. 
  805.  
  806.    3. "sockdmsg -l" to reset the sockd.log logging file. 
  807.  
  808.   This command works only when sockd is running because it uses the 
  809.  \QUEUES\SOCKD system queue to communicate with the sockd process. A parameter 
  810.  is MANDATORY. 
  811.  
  812.  
  813. ΓòÉΓòÉΓòÉ 13. SOCKS version 4 : A protocol for TCP proxy across firewalls ΓòÉΓòÉΓòÉ
  814.  
  815.  
  816.  A protocol for TCP proxy across firewalls 
  817.  
  818. SOCKS was originally developed by David Koblas and subsequently modified and 
  819. extended by Ying-Da Lee from NEC Systems Laboratory to its current running 
  820. version -- version 4. 
  821.  
  822. It is a protocol that relays TCP sessions at a firewall host to allow 
  823. application users transparent access across the firewall. Because the protocol 
  824. is independent of application protocols, it can be (and has been) used for many 
  825. different services, such as telnet, ftp, finger, whois, gopher, WWW,... 
  826.  
  827.  Access control can be applied at the beginning of each TCP session; thereafter 
  828. the server simply relays the data between the client and the application 
  829. server, incurring minimum processing overhead. Since SOCKS never has to know 
  830. anything about the application protocol, it should also be easy for it to 
  831. accommodate applications which use encryption to protect their traffic from 
  832. nosey snoopers. 
  833.  
  834.  Two operations are defined: CONNECT and BIND. 
  835.  
  836.  
  837. ΓòÉΓòÉΓòÉ 13.1. CONNECT ΓòÉΓòÉΓòÉ
  838.  
  839.  
  840.  The client connects to the SOCKS server and sends a CONNECT request when it 
  841. wants to establish a connection to an application server. The client includes 
  842. in the request packet the IP address and the port number of the destination 
  843. host, and userid, in the following format. 
  844.  
  845.        +----+----+----+----+----+----+----+----+----+----+....+----+
  846.        | VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|
  847.        +----+----+----+----+----+----+----+----+----+----+....+----+
  848. # bytes: 1    1      2              4           variable       1
  849.  
  850.  
  851.  VN is the SOCKS protocol version number and should be 4. CD is the SOCKS 
  852. command code and should be 1 for CONNECT request. NULL is a byte of all zero 
  853. bits. 
  854.  
  855.  The SOCKS server checks to see whether such a request should be granted based 
  856. on any combination of source IP address, destination IP address, destination 
  857. port number, the userid, and information it may obtain by consulting IDENT, cf. 
  858. RFC 1413.  If the request is granted, the SOCKS server makes a connection to 
  859. the specified port of the destination host. A reply packet is sent to the 
  860. client when this connection is established, or when the request is rejected or 
  861. the operation fails. 
  862.  
  863.  
  864.        +----+----+----+----+----+----+----+----+
  865.        | VN | CD | DSTPORT |      DSTIP        |
  866.        +----+----+----+----+----+----+----+----+
  867. # bytes: 1    1      2              4
  868.  
  869.  
  870.  VN is the version of the reply code and should be 0. CD is the result code 
  871. with one of the following values: 
  872.  
  873.  
  874.   90: request granted
  875.   91: request rejected or failed
  876.   92: request rejected becasue SOCKS server cannot connect to
  877.       identd on the client
  878.   93: request rejected because the client program and identd
  879.       report different user-ids
  880.  
  881.  
  882.  The remaining fields are ignored. 
  883.  
  884.  The SOCKS server closes its connection immediately after notifying the client 
  885. of a failed or rejected request. For a successful request, the SOCKS server 
  886. gets ready to relay traffic on both directions. This enables the client to do 
  887. I/O on its connection as if it were directly connected to the application 
  888. server. 
  889.  
  890.  
  891. ΓòÉΓòÉΓòÉ 13.2. BIND ΓòÉΓòÉΓòÉ
  892.  
  893.  
  894.  The client connects to the SOCKS server and sends a BIND request when it wants 
  895. to prepare for an inbound connection from an application server. This should 
  896. only happen after a primary connection to the application server has been 
  897. established with a CONNECT.  Typically, this is part of the sequence of 
  898. actions: 
  899.  
  900.    1. bind(): obtain a socket 
  901.  
  902.    2. getsockname(): get the IP address and port number of the socket 
  903.  
  904.    3. listen(): ready to accept call from the application server 
  905.  
  906.    4. use the primary connection to inform the application server of  the IP 
  907.       address and the port number that it should connect to. 
  908.  
  909.    5. accept(): accept a connection from the application server 
  910.  
  911.   The purpose of SOCKS BIND operation is to support such a sequence but using a 
  912.  socket on the SOCKS server rather than on the client. 
  913.  
  914.   The client includes in the request packet the IP address of the application 
  915.  server, the destination port used in the primary connection, and the userid. 
  916.  
  917.          +----+----+----+----+----+----+----+----+----+----+....+----+
  918.          | VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|
  919.          +----+----+----+----+----+----+----+----+----+----+....+----+
  920.   # bytes: 1    1      2              4           variable       1
  921.  
  922.   VN is again 4 for the SOCKS protocol version number. CD must be 2 to indicate 
  923.  BIND request. 
  924.  
  925.   The SOCKS server uses the client information to decide whether the request is 
  926.  to be granted. The reply it sends back to the client has the same format as 
  927.  the reply for CONNECT request, i.e., 
  928.  
  929.  
  930.         +----+----+----+----+----+----+----+----+
  931.         | VN | CD | DSTPORT |      DSTIP        |
  932.         +----+----+----+----+----+----+----+----+
  933.   #bytes: 1    1      2              4
  934.  
  935.   VN is the version of the reply code and should be 0. CD is the result code 
  936.  with one of the following values: 
  937.  
  938.  
  939.     90: request granted
  940.     91: request rejected or failed
  941.     92: request rejected becasue SOCKS server cannot connect to
  942.         identd on the client
  943.     93: request rejected because the client program and identd
  944.         report different user-ids.
  945.  
  946.  
  947.   However, for a granted request (CD is 90), the DSTPORT and DSTIP fields are 
  948.  meaningful.  In that case, the SOCKS server obtains a socket to wait for an 
  949.  incoming connection and sends the port number and the IP address of that 
  950.  socket to the client in DSTPORT and DSTIP, respectively. If the DSTIP in the 
  951.  reply is 0 (the value of constant INADDR_ANY), then the client should replace 
  952.  it by the IP address of the SOCKS server to which the cleint is connected. 
  953.  (This happens if the SOCKS server is not a multi-homed host.)  In the typical 
  954.  scenario, these two numbers are made available to the application client 
  955.  prgram via the result of the subsequent getsockname() call.  The application 
  956.  protocol must provide a way for these two pieces of information to be sent 
  957.  from the client to the application server so that it can initiate the 
  958.  connection, which connects it to the SOCKS server rather than directly to the 
  959.  application client as it normally would. 
  960.  
  961.   The SOCKS server sends a second reply packet to the client when the 
  962.  anticipated connection from the application server is established. The SOCKS 
  963.  server checks the IP address of the originating host against the value of 
  964.  DSTIP specified in the client's BIND request.  If a mismatch is found, the CD 
  965.  field in the second reply is set to 91 and the SOCKS server closes both 
  966.  connections.  If the two match, CD in the second reply is set to 90 and the 
  967.  SOCKS server gets ready to relay the traffic on its two connections. From then 
  968.  on the client does I/O on its connection to the SOCKS server as if it were 
  969.  directly connected to the application server. 
  970.  
  971.   For both CONNECT and BIND operations, the server sets a time limit (2 minutes 
  972.  in current CSTC implementation) for the establishment of its connection with 
  973.  the application server. If the connection is still not establiched when the 
  974.  time limit expires, the server closes its connection to the client and gives 
  975.  up. 
  976.  
  977.  
  978. ΓòÉΓòÉΓòÉ 14. SOCKS version 5 ΓòÉΓòÉΓòÉ
  979.  
  980.  
  981. ΓòÉΓòÉΓòÉ 14.1. RFC 1928 ΓòÉΓòÉΓòÉ
  982.  
  983. Network Working Group                                 M. Leech
  984. Request for Comments: 1928          Bell-Northern Research Ltd
  985. Category: Standards Track                             M. Ganis
  986.                                International Business Machines
  987.                                                         Y. Lee
  988.                                         NEC Systems Laboratory
  989.                                                       R. Kuris
  990.                                              Unify Corporation
  991.                                                      D. Koblas
  992.                                         Independent Consultant
  993.                                                       L. Jones
  994.                                        Hewlett-Packard Company
  995.                                                     March 1996
  996.  
  997.  
  998. ΓòÉΓòÉΓòÉ 14.2. Status of this Memo ΓòÉΓòÉΓòÉ
  999.  
  1000.  
  1001.  This document specifies an Internet standards track protocol for the  Internet 
  1002. community, and requests discussion and suggestions for  improvements.  Please 
  1003. refer to the current edition of the "Internet  Official Protocol Standards" 
  1004. (STD 1) for the standardization state  and status of this protocol. 
  1005. Distribution of this memo is unlimited. 
  1006.  
  1007.  Acknowledgments 
  1008.  
  1009.  This memo describes a protocol that is an evolution  of  the  previous 
  1010. version  of  the protocol, version 4 [1]. This new  protocol stems from active 
  1011. discussions and prototype  implementations  The  key contributors are: Marcus 
  1012. Leech: Bell-Northern Research,  David  Koblas:  Independent  Consultant, 
  1013. Ying-Da  Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard  Company, 
  1014. Ron Kuris: Unify Corporation,  Matt  Ganis:  International Business Machines. 
  1015.  
  1016.  Introduction 
  1017.  
  1018.  The use of network firewalls, systems that effectively isolate an 
  1019. organizations internal network structure from an exterior network,  such as the 
  1020. INTERNET is becoming increasingly popular.  These  firewall systems typically 
  1021. act as application-layer gateways between  networks, usually offering 
  1022. controlled TELNET, FTP, and SMTP access.  With the emergence of more 
  1023. sophisticated application layer protocols  designed to facilitate global 
  1024. information discovery, there exists a  need to provide a general framework for 
  1025. these protocols to  transparently and securely traverse a firewall. 
  1026.  
  1027.  There exists, also, a need for strong authentication of such  traversal in as 
  1028. fine-grained a manner as is practical. This  requirement stems from the 
  1029. realization that client-server  relationships emerge between the networks of 
  1030. various organizations,  and that such relationships need to be controlled and 
  1031. often strongly  authenticated. 
  1032.  
  1033.  The  protocol described here is designed to provide a frame-  work for 
  1034. client-server applications in both the TCP and  UDP  domains  to  conveniently 
  1035. and securely use the services of a  network firewall.  The protocol  is 
  1036. conceptually  a  "shimlayer"  between the application layer and the transport 
  1037. layer  and as such does not provide network-layer gateway  services  such as 
  1038. forwarding of ICMP messages. 
  1039.  
  1040.  This  new  protocol extends the SOCKS Version 4 model to include  UDP, and 
  1041. extends the framework to  include  provisions  for  generalized  strong 
  1042. authentication schemes, and extends  the addressing scheme to encompass 
  1043. domain-name and V6 IP addresses. 
  1044.  
  1045.  
  1046. ΓòÉΓòÉΓòÉ 14.3. Procedure for TCP-based clients ΓòÉΓòÉΓòÉ
  1047.  
  1048.  
  1049.  When a TCP-based client wishes to establish a connection  to  an object that 
  1050. is reachable only via a firewall (such determination  is left up to the 
  1051. implementation), it must  open  a  TCP  connection  to  the appropriate SOCKS 
  1052. port on the SOCKS  server system.  The SOCKS service is conventionally  located 
  1053. on  TCP  port 1080.  If the connection request succeeds, the  client enters a 
  1054. negotiation for the authentication method to  be  used, authenticates with the 
  1055. chosen method, then sends a  relay request.  The SOCKS server evaluates the 
  1056. request,  and  either  establishes the appropriate connection or denies it. 
  1057.  
  1058.  The client connects to the server, and sends a version    identifier/method 
  1059. selection message: 
  1060.  
  1061.   +----+----------+----------+
  1062.   |VER | NMETHODS | METHODS  |
  1063.   +----+----------+----------+
  1064.   | 1  |    1     | 1 to 255 |
  1065.   +----+----------+----------+
  1066.  
  1067.  The VER field is set to X'05' for this version of the protocol.-  The NMETHODS 
  1068. field contains the number of method identifier  octets that appear in the 
  1069. METHODS field. 
  1070.  
  1071.  The server selects from one of the methods given in METHODS,  and sends a 
  1072. METHOD selection message: 
  1073.  
  1074.  
  1075.    +----+--------+
  1076.    |VER | METHOD |
  1077.    +----+--------+
  1078.    | 1  |   1    |
  1079.    +----+--------+
  1080.  
  1081.  If the selected METHOD is X'FF', none of the methods  listed  by  the client 
  1082. are acceptable, and the client MUST close the  connection. 
  1083.  
  1084.  The values currently defined for METHOD are: 
  1085.  
  1086.  
  1087.   o  X'00' NO AUTHENTICATION REQUIRED
  1088.   o  X'01' <A HREF=/draft-ietf-aft-gssapi-02.html>GSSAPI</A>
  1089.   o  X'02' <A HREF=/draft-ietf-aft-username-password-01.html>USERNAME/PASSWORD</A>
  1090.  
  1091.   o  X'03' to X'7F' IANA ASSIGNED
  1092.  
  1093.   o  X'80' to X'FE' RESERVED FOR PRIVATE METHODS
  1094.  
  1095.   o  X'FF' NO ACCEPTABLE METHODS
  1096.  
  1097.  The client and server then enter a method-specific  subnegotiation 
  1098. Descriptions  of the method-dependent subnegotiations  appear in separate 
  1099. drafts. 
  1100.  
  1101.  Developers of new METHOD support for  this  protocol  should  contact IANA for 
  1102. a METHOD number.  The ASSIGNED NUMBERS document  should be referred to for a 
  1103. current  list  of  METHOD  numbers and their corresponding protocols. 
  1104.  
  1105.  Compliant  implementations  MUST  support  GSSAPI and SHOULD  support 
  1106. USERNAME/PASSWORD authentication methods. 
  1107.  
  1108.  
  1109.   The SOCKS request is formed as follows:
  1110.  
  1111.   +----+-----+-------+------+----------+----------+
  1112.   |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
  1113.   +----+-----+-------+------+----------+----------+
  1114.   | 1  |  1  | X'00' |  1   | Variable |    2     |
  1115.   +----+-----+-------+------+----------+----------+
  1116.  Where:
  1117.  
  1118.   o  VER    protocol version: X'05'
  1119.   o  CMD
  1120.   o  CONNECT X'01'
  1121.   o  BIND X'02'
  1122.   o  UDP ASSOCIATE X'03'
  1123.   o  RSV    RESERVED
  1124.   o  ATYP   address type of following address
  1125.      o  IP V4 address: X'01'
  1126.      o  DOMAINNAME: X'03'
  1127.      o  IP V6 address: X'04'
  1128.   o  DST.ADDR       desired destination address
  1129.   o  DST.PORT       desired destination port in network octet order
  1130.  
  1131.  The SOCKS server will typically evaluate the  request  based  on  source and 
  1132. destination addresses, and return one or more  reply messages, as appropriate 
  1133. for the request type. 
  1134.  
  1135.  
  1136. ΓòÉΓòÉΓòÉ 14.4. Addressing ΓòÉΓòÉΓòÉ
  1137.  
  1138.  
  1139.  In an address field (DST.ADDR,  BND.ADDR),  the  ATYP  field  specifies the 
  1140. type of address contained within the field: 
  1141.  
  1142.      X'01' 
  1143.  
  1144.        the  address  is  a version-4 IP address, with a length of 4  octets 
  1145.  
  1146.      X'03' 
  1147.  
  1148.        the address field contains a  DNS-style  domain  name.  The  first 
  1149.       octet  of  the  address  field contains the number of  octets that 
  1150.       follow. 
  1151.  
  1152.      X'04' 
  1153.  
  1154.        the address is a version-6 IP address, with a length  of  16  octets. 
  1155.  
  1156.   Address resolution proxy: Because of the protocol limitation, Version 4 based 
  1157.  SOCKS servers require full DNS support to be operational (every SOCKS V4 
  1158.  client must be able to resolve all the accessible destination addresses). 
  1159.  The built-in address resolution proxy in Version 5 based SOCKS server will 
  1160.  enables SOCKS V5 clients to be fully operational without having DNS support. A 
  1161.  SOCKS client can pass the name, instead of resolved address, to the SOCKS 
  1162.  server and the server will resolve the address for the client. 
  1163.  
  1164.  
  1165. ΓòÉΓòÉΓòÉ 14.5. Replies ΓòÉΓòÉΓòÉ
  1166.  
  1167.  
  1168.  The  SOCKS request information is sent by the client as soon  as it has 
  1169. established a connection to the SOCKS server,  and  completed the 
  1170. authentication negotiations.  The server  evaluates the request, and returns a 
  1171. reply formed as follows: 
  1172.  
  1173.  
  1174.   +----+-----+-------+------+----------+----------+
  1175.   |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
  1176.   +----+-----+-------+------+----------+----------+
  1177.   | 1  |  1  | X'00' |  1   | Variable |    2     |
  1178.   +----+-----+-------+------+----------+----------+
  1179.  Where:
  1180.  
  1181.  
  1182.    o  VER    protocol version: X'05'
  1183.    o  REP    Reply field:
  1184.       o  X'00' succeeded
  1185.       o  X'01' general SOCKS server failure
  1186.       o  X'02' connection not allowed by ruleset
  1187.       o  X'03' Network unreachable
  1188.       o  X'04' Host unreachable
  1189.       o  X'05' Connection refused
  1190.       o  X'06' TTL expired
  1191.       o  X'07' Command not supported
  1192.       o  X'08' Address type not supported
  1193.       o  X'09' to X'FF' unassigned
  1194.    o  RSV    RESERVED
  1195.    o  ATYP   address type of following address
  1196.       o  IP V4 address: X'01'
  1197.       o  DOMAINNAME: X'03'
  1198.       o  IP V6 address: X'04'
  1199.    o  BND.ADDR       server bound address
  1200.    o  BND.PORT       server bound port in network octet order
  1201.  
  1202.   Fields marked RESERVED (RSV) must be set to X'00'.
  1203.  
  1204.  If the chosen method includes encapsulation for purposes  of  authentication, 
  1205. integrity  and/or  confidentiality,  the  replies are encapsulated in the 
  1206. method-dependent  encapsulation. 
  1207.  
  1208.  CONNECT 
  1209.  
  1210.  In the reply to a CONNECT, BND.PORT contains the port number  that the server 
  1211. assigned to  connect  to  the  target  host,  while BND.ADDR contains the 
  1212. associated IP address.  The supplied  BND.ADDR is often different from the IP 
  1213. address  that  the  client  uses  to  reach  the  SOCKS  server, since such 
  1214. servers are often multi-homed.  It  is  expected  that  the  SOCKS server will 
  1215. use DST.ADDR and DST.PORT, and the client-  side source address and port in 
  1216. evaluating the  CONNECT  request. 
  1217.  
  1218.  BIND 
  1219.  
  1220.  The  BIND  request  is  used  in protocols which require the  client to accept 
  1221. connections from  the  server.  FTP  is  a  well-known  example, which uses the 
  1222. primary client-to-server  connection for commands and status reports, but  may 
  1223. use  a  server-to-client  connection for transferring data on demand  (e.g. LS, 
  1224. GET, PUT). 
  1225.  
  1226.  It is expected that the client side of an application protocol  will  use  the 
  1227. BIND request only to establish secondary  connections after a primary 
  1228. connection is established  using  CONNECT.  In  is  expected  that  a  SOCKS 
  1229. server will use  DST.ADDR and DST.PORT in evaluating the BIND request. 
  1230.  
  1231.  Two replies are sent from the SOCKS  server  to  the  client  during a BIND 
  1232. operation.  The first is sent after the server  creates and binds a new socket. 
  1233. The BND.PORT field contains  the port number that the SOCKS server assigned to 
  1234. listen for  an incoming connection.  The BND.ADDR field contains the 
  1235. associated  IP  address.  The client will typically use these  pieces of 
  1236. information to notify (via the primary or  control  connection)  the 
  1237. application  server  of the rendezvous address.  The second reply occurs only 
  1238. after  the  anticipated  incoming connection succeeds or fails. 
  1239.  
  1240.  In  the  second reply, the BND.PORT and BND.ADDR fields contain  the address 
  1241. and port number of the connecting host. 
  1242.  
  1243.  UDP ASSOCIATE 
  1244.  
  1245.  The UDP ASSOCIATE request is used to establish  an  association  within  the 
  1246. UDP relay process to handle UDP datagrams.  The DST.ADDR and DST.PORT fields 
  1247. contain  the  address  and  port that the client expects to use to send UDP 
  1248. datagrams on  for the association.  The server MAY use this information to 
  1249. limit  access  to  the association.  If the client is not in  possesion of the 
  1250. information at the time of the UDP  ASSOCIATE,  the  client  MUST use a port 
  1251. number and address of all  zeros. 
  1252.  
  1253.  A UDP association terminates when the  TCP  connection  that  the UDP 
  1254. ASSOCIATE request arrived on terminates. 
  1255.  
  1256.  In  the  reply  to a UDP ASSOCIATE request, the BND.PORT and  BND.ADDR fields 
  1257. indicate the port number/address  where  the  client MUST send UDP request 
  1258. messages to be relayed. 
  1259.  
  1260.  Reply Processing 
  1261.  
  1262.  When  a reply (REP value other than X'00') indicates a failure,  the SOCKS 
  1263. server  MUST  terminate  the  TCP  connection  shortly  after sending the 
  1264. reply.  This must be no more than  10 seconds after detecting the condition 
  1265. that caused a failure. 
  1266.  
  1267.  If  the reply code (REP value of X'00') indicates a success,  and the request 
  1268. was either a BIND or a CONNECT,  the  client  may  now start passing data.  If 
  1269. the selected authentication  method supports encapsulation for the purposes of 
  1270. integrity,  authentication and/or confidentiality, the data are encapsulated 
  1271. using the method-dependent encapsulation.  Similarly,  when  data  arrives  at 
  1272. the SOCKS server for the client, the  server MUST encapsulate the data as 
  1273. appropriate for the  authentication method in use. 
  1274.  
  1275.  Procedure for UDP-based clients 
  1276.  
  1277.  A  UDP-based client MUST send its datagrams to the UDP relay  server at the 
  1278. UDP port indicated by BND.PORT in the reply to  the  UDP  ASSOCIATE request. 
  1279. If the selected authentication  method provides encapsulation for the purposes 
  1280. of authenticity,  integrity, and/or confidentiality, the datagram MUST be 
  1281. encapsulated using the appropriate encapsulation.  Each  UDP  datagram carries 
  1282. a UDP request header with it: 
  1283.  
  1284.      +----+------+------+----------+----------+----------+
  1285.      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
  1286.      +----+------+------+----------+----------+----------+
  1287.      | 2  |  1   |  1   | Variable |    2     | Variable |
  1288.      +----+------+------+----------+----------+----------+
  1289.  The fields in the UDP request header are:
  1290.  
  1291.       o  RSV  Reserved X'0000'
  1292.       o  FRAG    Current fragment number
  1293.       o  ATYP    address type of following addresses:
  1294.          o  IP V4 address: X'01'
  1295.          o  DOMAINNAME: X'03'
  1296.          o  IP V6 address: X'04'
  1297.       o  DST.ADDR       desired destination address
  1298.       o  DST.PORT       desired destination port
  1299.       o  DATA     user data
  1300.  
  1301.  When  a UDP relay server decides to relay a UDP datagram, it  does so 
  1302. silently, without any notification to the requesting  client.  Similarly, it 
  1303. will drop datagrams it cannot or will  not relay.  When a UDP relay server 
  1304. receives a  reply  datagram  from  a remote host, it MUST encapsulate that 
  1305. datagram  using the above UDP request header, and any  authentication- 
  1306. method-dependent encapsulation. 
  1307.  
  1308.  The  UDP relay server MUST acquire from the SOCKS server the  expected IP 
  1309. address of the client that will  send  datagrams  to  the  BND.PORT  given  in 
  1310. the reply to UDP ASSOCIATE.  It  MUST drop any datagrams arriving from any 
  1311. source IP  address  other  than the one recorded for the particular 
  1312. association. 
  1313.  
  1314.  The FRAG field indicates whether or not this datagram is one  of  a  number 
  1315. of fragments.  If implemented, the high-order  bit indicates end-of-fragment 
  1316. sequence,  while  a  value  of  X'00'  indicates  that  this datagram is 
  1317. standalone.  Values  between 1 and 127 indicate the fragment  position  within 
  1318. a  fragment  sequence.  Each  receiver  will have a REASSEMBLY  QUEUE and a 
  1319. REASSEMBLY TIMER  associated  with  these  fragments.  The  reassembly queue 
  1320. must be reinitialized and the  associated fragments abandoned whenever the 
  1321. REASSEMBLY TIMER  expires,  or  a  new  datagram arrives carrying a FRAG field 
  1322. whose value is less than the highest  FRAG  value  processed  for this fragment 
  1323. sequence.  The reassembly timer MUST be no  less than 5 seconds.  It is 
  1324. recommended  that  fragmentation  be avoided by applications wherever possible. 
  1325.  
  1326.  Implementation  of fragmentation is optional; an implementation  that does not 
  1327. support fragmentation MUST drop any datagram  whose FRAG field is other than 
  1328. X'00'. 
  1329.  
  1330.  The  programming interface for a SOCKS-aware UDP MUST report  an available 
  1331. buffer space for UDP datagrams that is  smaller  than the actual space provided 
  1332. by the operating system: 
  1333.  
  1334.  
  1335.   o  if ATYP is X'01' - 10+method_dependent octets smaller
  1336.   o  if ATYP is X'03' - 262+method_dependent octets smaller
  1337.   o  if ATYP is X'04' - 20+method_dependent octets smaller
  1338.  
  1339.  
  1340. ΓòÉΓòÉΓòÉ 14.6. Security Considerations ΓòÉΓòÉΓòÉ
  1341.  
  1342.  
  1343.  This document describes a protocol for the application-layer  traversal of IP 
  1344. network firewalls.  The  security  of  such  traversal  is highly dependent on 
  1345. the particular authentication  and encapsulation methods provided in a 
  1346. particular  implementation,  and selected during negotiation between SOCKS 
  1347. client and SOCKS server. 
  1348.  
  1349.  Careful consideration should be given by  the  administrator  to the selection 
  1350. of authentication methods. 
  1351.  
  1352.  Authors Address 
  1353.  
  1354.   Marcus Leech
  1355.   Bell-Northern Research
  1356.   P.O. Box 3511, Stn. C,
  1357.   Ottawa, ON
  1358.   CANADA K1Y 4H7
  1359.  
  1360.   Email: mleech@bnr.ca
  1361.  
  1362.  
  1363. ΓòÉΓòÉΓòÉ 14.7. Username/Password Authentication for SOCKS V5 ΓòÉΓòÉΓòÉ
  1364.  
  1365.  Username/Password Authentication for SOCKS V5 
  1366.  
  1367. Network Working Group                         M. Leech
  1368. Request for Comments: 1929  Bell-Northern Research Ltd
  1369. Category: Standards Track                   March 1996
  1370.  
  1371.  Status of this Memo 
  1372.  
  1373.  This document specifies an Internet standards track protocol for the  Internet 
  1374. community, and requests discussion and suggestions for  improvements.  Please 
  1375. refer to the current edition of the "Internet  Official Protocol Standards" 
  1376. (STD 1) for the standardization state  and status of this protocol. 
  1377. Distribution of this memo is unlimited. 
  1378.  
  1379.  Introduction 
  1380.  
  1381.  The protocol specification for SOCKS Version 5 specifies a  generalized 
  1382. framework for the use of arbitrary authentication  protocols in the initial 
  1383. socks connection setup. This document  describes one of those protocols, as it 
  1384. fits into the SOCKS Version 5  authentication "subnegotiation". 
  1385. Note: 
  1386.  
  1387.  Unless otherwise noted, the decimal numbers appearing in packet-  format 
  1388. diagrams represent the length of the corresponding field, in  octets.  Where a 
  1389. given octet must take on a specific value, the  syntax X'hh' is used to denote 
  1390. the value of the single octet in that  field. When the word 'Variable' is used, 
  1391. it indicates that the  corresponding field has a variable length defined either 
  1392. by an  associated (one or two octet) length field, or by a data type field. 
  1393.  
  1394.  Initial negotiation 
  1395.  
  1396.  Once the SOCKS V5 server has started, and the client has selected the 
  1397. Username/Password Authentication protocol, the Username/Password 
  1398. subnegotiation begins.  This begins with the client producing a 
  1399. Username/Password request: 
  1400.  
  1401.  
  1402.  +----+------+----------+------+----------+
  1403.  |VER | ULEN |  UNAME   | PLEN |  PASSWD  |
  1404.  +----+------+----------+------+----------+
  1405.  | 1  |  1   | 1 to 255 |  1   | 1 to 255 |
  1406.  +----+------+----------+------+----------+
  1407.  
  1408.  
  1409.  The VER field contains the current version of the subnegotiation,  which is 
  1410. X'01'. The ULEN field contains the  length of the UNAME field that follows. The 
  1411. UNAME field  contains the username as known to the source operating  system. 
  1412. The PLEN field contains the length of the PASSWD  field that follows. The 
  1413. PASSWD field contains the pass-  word association with the given UNAME. 
  1414.  
  1415.  The server verifies the supplied UNAME and PASSWD, and  sends the following 
  1416. response: 
  1417.  
  1418.  
  1419.      +----+--------+
  1420.      |VER | STATUS |
  1421.      +----+--------+
  1422.      | 1  |   1    |
  1423.      +----+--------+
  1424.  
  1425.  A STATUS field of X'00' indicates success. If the server  returns a `failure' 
  1426. (STATUS value other than X'00') status,  it MUST close the connection. 
  1427.  
  1428.  Security Considerations 
  1429.  
  1430.  This document describes a subnegotiation that provides authentication 
  1431. services to the SOCKS protocol. Since the request carries the  password in 
  1432. cleartext, this subnegotiation is not recommended for  environments where 
  1433. "sniffing" is possible and practical. 
  1434.  
  1435.  Authors Address 
  1436.  
  1437.    Marcus Leech
  1438.    Bell-Northern Research Ltd
  1439.    P.O. Box 3511, Station C
  1440.    Ottawa, ON
  1441.    CANADA K1Y 4H7
  1442.  
  1443.    +1 613 763 9145
  1444.  
  1445.    Email: mleech@bnr.ca
  1446.  
  1447.  
  1448. ΓòÉΓòÉΓòÉ 15. RFC1918 : Address Allocation for Private Internets ΓòÉΓòÉΓòÉ
  1449.  
  1450. Network Working Group                               Y. Rekhter
  1451. Request for Comments: 1918                       Cisco Systems
  1452. Obsoletes: 1627, 1597                             B. Moskowitz
  1453. BCP: 5                                          Chrysler Corp.
  1454. Category: Best Current Practice                  D. Karrenberg
  1455.                                                       RIPE NCC
  1456.                                                 G. J. de Groot
  1457.                                                       RIPE NCC
  1458.                                                        E. Lear
  1459.                                         Silicon Graphics, Inc.
  1460.                                                  February 1996
  1461.  
  1462.  
  1463. ΓòÉΓòÉΓòÉ 15.1. Status of this Memo ΓòÉΓòÉΓòÉ
  1464.  
  1465.  
  1466.  This document specifies an Internet Best Current Practices for the  Internet 
  1467. Community, and requests discussion and suggestions for  improvements. 
  1468. Distribution of this memo is unlimited. 
  1469.  
  1470.  
  1471. ΓòÉΓòÉΓòÉ 15.2. Introduction ΓòÉΓòÉΓòÉ
  1472.  
  1473.  
  1474.  For the purposes of this document, an enterprise is an entity  autonomously 
  1475. operating a network using TCP/IP and in particular  determining the addressing 
  1476. plan and address assignments within that  network. 
  1477.  
  1478.  This document describes address allocation for private internets. The 
  1479. allocation permits full network layer connectivity among all hosts  inside an 
  1480. enterprise as well as among all public hosts of different  enterprises. The 
  1481. cost of using private internet address space is the  potentially costly effort 
  1482. to renumber hosts and networks between  public and private. 
  1483.  
  1484.  
  1485. ΓòÉΓòÉΓòÉ 15.3. Motivation ΓòÉΓòÉΓòÉ
  1486.  
  1487.  
  1488.  With the proliferation of TCP/IP technology worldwide, including  outside the 
  1489. Internet itself, an increasing number of non-connected  enterprises use this 
  1490. technology and its addressing capabilities for  sole intra-enterprise 
  1491. communications, without any intention to ever  directly connect to other 
  1492. enterprises or the Internet itself. 
  1493.  
  1494.  The Internet has grown beyond anyone's expectations. Sustained  exponential 
  1495. growth continues to introduce new challenges.  One  challenge is a concern 
  1496. within the community that globally unique  address space will be exhausted. A 
  1497. separate and far more pressing  concern is that the amount of routing overhead 
  1498. will grow beyond the  capabilities of Internet Service Providers. Efforts are 
  1499. in progress  within the community to find long term solutions to both of these 
  1500. problems. Meanwhile it is necessary to revisit address allocation  procedures, 
  1501. and their impact on the Internet routing system. 
  1502.  
  1503.  To contain growth of routing overhead, an Internet Provider obtains a  block 
  1504. of address space from an address registry, and then assigns to  its customers 
  1505. addresses from within that block based on each customer  requirement. The 
  1506. result of this process is that routes to many  customers will be aggregated 
  1507. together, and will appear to other  providers as a single route ΓòÆRFC1518Γûá, 
  1508. ΓòÆRFC1519Γûá.  In order for route  aggregation to be effective, Internet providers 
  1509. encourage customers  joining their network to use the provider's block, and 
  1510. thus renumber  their computers. Such encouragement may become a requirement in 
  1511. the  future. 
  1512.  
  1513.  With the current size of the Internet and its growth rate it is no  longer 
  1514. realistic to assume that by virtue of acquiring globally  unique IP addresses 
  1515. out of an Internet registry an organization that  acquires such addresses would 
  1516. have Internet-wide IP connectivity once  the organization gets connected to the 
  1517. Internet. To the contrary, it  is quite likely that when the organization would 
  1518. connect to the  Internet to achieve Internet-wide IP connectivity the 
  1519. organization  would need to change IP addresses (renumber) all of its public 
  1520. hosts  (hosts that require Internet-wide IP connectivity), regardless of 
  1521. whether the addresses used by the organization initially were  globally unique 
  1522. or not. 
  1523.  
  1524.  It has been typical to assign globally unique addresses to all hosts  that use 
  1525. TCP/IP. In order to extend the life of the IPv4 address  space, address 
  1526. registries are requiring more justification than ever  before, making it harder 
  1527. for organizations to acquire additional  address space ΓòÆRFC1466Γûá. 
  1528.  
  1529.  Hosts within enterprises that use IP can be partitioned into three 
  1530. categories: 
  1531.  
  1532.      Category 1: hosts that do not require access to hosts in other 
  1533.       enterprises or the Internet at large; hosts within  this category may use 
  1534.       IP addresses that are  unambiguous within an enterprise, but may be 
  1535.       ambiguous between enterprises. 
  1536.  
  1537.      Category 2: hosts that need access to a limited set of outside  services 
  1538.       (e.g., E-mail, FTP, netnews, remote login)  which can be handled by 
  1539.       mediating gateways (e.g.,  application layer gateways). For many hosts in 
  1540.       this  category an unrestricted external access (provided  via IP 
  1541.       connectivity) may be unnecessary and even  undesirable for 
  1542.       privacy/security reasons. Just like  hosts within the first category, 
  1543.       such hosts may use  IP addresses that are unambiguous within an 
  1544.       enterprise, but may be ambiguous between  enterprises. 
  1545.  
  1546.      Category 3: hosts that need network layer access outside the  enterprise 
  1547.       (provided via IP connectivity); hosts in  the last category require IP 
  1548.       addresses that are  globally unambiguous. 
  1549.  
  1550.   We will refer to the hosts in the first and second categories as  "private". 
  1551.  We will refer to the hosts in the third category as  "public". 
  1552.  
  1553.   Many applications require connectivity only within one enterprise and  do not 
  1554.  need external (outside the enterprise) connectivity for the  majority of 
  1555.  internal hosts. In larger enterprises it is often easy to  identify a 
  1556.  substantial number of hosts using TCP/IP that do not need  network layer 
  1557.  connectivity outside the enterprise. 
  1558.  
  1559.   Some examples, where external connectivity might not be required,  are: 
  1560.  
  1561.      A large airport which has its arrival/departure displays  individually 
  1562.       addressable via TCP/IP. It is very unlikely  that these displays need to 
  1563.       be directly accessible from  other networks. 
  1564.  
  1565.      Large organizations like banks and retail chains are  switching to TCP/IP 
  1566.       for their internal communication. Large  numbers of local workstations 
  1567.       like cash registers, money  machines, and equipment at clerical positions 
  1568.       rarely need  to have such connectivity. 
  1569.  
  1570.      For security reasons, many enterprises use application  layer gateways to 
  1571.       connect their internal network to the  Internet.  The internal network 
  1572.       usually does not have  direct access to the Internet, thus only one or 
  1573.       more  gateways are visible from the Internet. In this case, the  internal 
  1574.       network can use non-unique IP network numbers. 
  1575.  
  1576.      Interfaces of routers on an internal network usually do not  need to be 
  1577.       directly accessible from outside the enterprise. 
  1578.  
  1579.  
  1580. ΓòÉΓòÉΓòÉ 15.4. Private Address Space ΓòÉΓòÉΓòÉ
  1581.  
  1582.  
  1583.  The Internet Assigned Numbers Authority (IANA) has reserved the  following 
  1584. three blocks of the IP address space for private internets: 
  1585.  
  1586.  
  1587.      10.0.0.0        -   10.255.255.255  (10/8 prefix)
  1588.      172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
  1589.      192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
  1590.  
  1591.  
  1592.  We will refer to the first block as "24-bit block", the second as  "20-bit 
  1593. block", and to the third as "16-bit" block. Note that (in  pre-CIDR notation) 
  1594. the first block is nothing but a single class A  network number, while the 
  1595. second block is a set of 16 contiguous  class B network numbers, and third 
  1596. block is a set of 256 contiguous  class C network numbers. 
  1597.  
  1598.  An enterprise that decides to use IP addresses out of the address  space 
  1599. defined in this document can do so without any coordination  with IANA or an 
  1600. Internet registry. The address space can thus be used  by many enterprises. 
  1601. Addresses within this private address space will  only be unique within the 
  1602. enterprise, or the set of enterprises which  choose to cooperate over this 
  1603. space so they may communicate with each  other in their own private internet. 
  1604.  
  1605.  As before, any enterprise that needs globally unique address space is 
  1606. required to obtain such addresses from an Internet registry. An  enterprise 
  1607. that requests IP addresses for its external connectivity  will never be 
  1608. assigned addresses from the blocks defined above. 
  1609.  
  1610.  In order to use private address space, an enterprise needs to  determine which 
  1611. hosts do not need to have network layer connectivity  outside the enterprise in 
  1612. the foreseeable future and thus could be  classified as private. Such hosts 
  1613. will use the private address space  defined above.  Private hosts can 
  1614. communicate with all other hosts  inside the enterprise, both public and 
  1615. private. However, they cannot  have IP connectivity to any host outside of the 
  1616. enterprise. While not  having external (outside of the enterprise) IP 
  1617. connectivity private  hosts can still have access to external services via 
  1618. mediating  gateways (e.g., application layer gateways). 
  1619.  
  1620.  All other hosts will be public and will use globally unique address  space 
  1621. assigned by an Internet Registry. Public hosts can communicate  with other 
  1622. hosts inside the enterprise both public and private and  can have IP 
  1623. connectivity to public hosts outside the enterprise.  Public hosts do not have 
  1624. connectivity to private hosts of other  enterprises. 
  1625.  
  1626.  Moving a host from private to public or vice versa involves a change  of IP 
  1627. address, changes to the appropriate DNS entries, and changes to  configuration 
  1628. files on other hosts that reference the host by IP  address. 
  1629.  
  1630.  Because private addresses have no global meaning, routing information  about 
  1631. private networks shall not be propagated on inter-enterprise  links, and 
  1632. packets with private source or destination addresses  should not be forwarded 
  1633. across such links. Routers in networks not  using private address space, 
  1634. especially those of Internet service  providers, are expected to be configured 
  1635. to reject (filter out)  routing information about private networks. If such a 
  1636. router receives  such information the rejection shall not be treated as a 
  1637. routing  protocol error. 
  1638.  
  1639.  Indirect references to such addresses should be contained within the 
  1640. enterprise. Prominent examples of such references are DNS Resource  Records and 
  1641. other information referring to internal private  addresses. In particular, 
  1642. Internet service providers should take  measures to prevent such leakage. 
  1643.  
  1644.  
  1645. ΓòÉΓòÉΓòÉ 15.5. Advantages and Disadvantages of Using Private Address Space ΓòÉΓòÉΓòÉ
  1646.  
  1647.  
  1648.  The obvious advantage of using private address space for the Internet  at 
  1649. large is to conserve the globally unique address space by not  using it where 
  1650. global uniqueness is not required. 
  1651.  
  1652.  Enterprises themselves also enjoy a number of benefits from their  usage of 
  1653. private address space: They gain a lot of flexibility in  network design by 
  1654. having more address space at their disposal than  they could obtain from the 
  1655. globally unique pool. This enables  operationally and administratively 
  1656. convenient addressing schemes as  well as easier growth paths. 
  1657.  
  1658.  For a variety of reasons the Internet has already encountered  situations 
  1659. where an enterprise that has not been connected to the  Internet had used IP 
  1660. address space for its hosts without getting this  space assigned from the IANA. 
  1661. In some cases this address space had  been already assigned to other 
  1662. enterprises. If such an enterprise  would later connects to the Internet, this 
  1663. could potentially create  very serious problems, as IP routing cannot provide 
  1664. correct  operations in presence of ambiguous addressing. Although in principle 
  1665. Internet Service Providers should guard against such mistakes through  the use 
  1666. of route filters, this does not always happen in practice.  Using private 
  1667. address space provides a safe choice for such  enterprises, avoiding clashes 
  1668. once outside connectivity is needed. 
  1669.  
  1670.  A major drawback to the use of private address space is that it may  actually 
  1671. reduce an enterprise's flexibility to access the Internet.  Once one commits to 
  1672. using a private address, one is committing to  renumber part or all of an 
  1673. enterprise, should one decide to provide  IP connectivity between that part (or 
  1674. all of the enterprise) and the  Internet.  Usually the cost of renumbering can 
  1675. be measured by  counting the number of hosts that have to transition from 
  1676. private to  public. As was discussed earlier, however, even if a network uses 
  1677. globally unique addresses, it may still have to renumber in order to  acquire 
  1678. Internet-wide IP connectivity. 
  1679.  
  1680.  Another drawback to the use of private address space is that it may  require 
  1681. renumbering when merging several private internets into a  single private 
  1682. internet. If we review the examples we list in Section  2, we note that 
  1683. companies tend to merge. If such companies prior to  the merge maintained their 
  1684. uncoordinated internets using private  address space, then if after the merge 
  1685. these private internets would  be combined into a single private internet, some 
  1686. addresses within the  combined private internet may not be unique. As a result, 
  1687. hosts with  these addresses would need to be renumbered. 
  1688.  
  1689.  The cost of renumbering may well be mitigated by development and  deployment 
  1690. of tools that facilitate renumbering (e.g.  Dynamic Host  Configuration 
  1691. Protocol (DHCP)). When deciding whether to use private  addresses, we recommend 
  1692. to inquire computer and software vendors  about availability of such tools.  A 
  1693. separate IETF effort (PIER  Working Group) is pursuing full documentation of 
  1694. the requirements and  procedures for renumbering. 
  1695.  
  1696.  
  1697. ΓòÉΓòÉΓòÉ 15.6. Operational Considerations ΓòÉΓòÉΓòÉ
  1698.  
  1699.  
  1700.  One possible strategy is to design the private part of the network  first and 
  1701. use private address space for all internal links. Then plan  public subnets at 
  1702. the locations needed and design the external  connectivity. 
  1703.  
  1704.  This design does not need to be fixed permanently. If a group of one  or more 
  1705. hosts requires to change their status (from private to public  or vice versa) 
  1706. later, this can be accomplished by renumbering only  the hosts involved, and 
  1707. changing physical connectivity, if needed. In  locations where such changes can 
  1708. be foreseen (machine rooms, etc.),  it is advisable to configure separate 
  1709. physical media for public and  private subnets to facilitate such changes.  In 
  1710. order to avoid major  network disruptions, it is advisable to group hosts with 
  1711. similar  connectivity needs on their own subnets. 
  1712.  
  1713.  If a suitable subnetting scheme can be designed and is supported by  the 
  1714. equipment concerned, it is advisable to use the 24-bit block  (class A network) 
  1715. of private address space and make an addressing  plan with a good growth path. 
  1716. If subnetting is a problem, the 16-bit  block (class C networks), or the 20-bit 
  1717. block (class B networks) of  private address space can be used. 
  1718.  
  1719.  One might be tempted to have both public and private addresses on the  same 
  1720. physical medium. While this is possible, there are pitfalls to  such a design 
  1721. (note that the pitfalls have nothing to do with the use  of private addresses, 
  1722. but are due to the presence of multiple IP  subnets on a common Data Link 
  1723. subnetwork).  We advise caution when  proceeding in this area. 
  1724.  
  1725.  It is strongly recommended that routers which connect enterprises to  external 
  1726. networks are set up with appropriate packet and routing  filters at both ends 
  1727. of the link in order to prevent packet and  routing information leakage. An 
  1728. enterprise should also filter any  private networks from inbound routing 
  1729. information in order to protect  itself from ambiguous routing situations which 
  1730. can occur if routes to  the private address space point outside the enterprise. 
  1731.  
  1732.  It is possible for two sites, who both coordinate their private  address 
  1733. space, to communicate with each other over a public network.  To do so they 
  1734. must use some method of encapsulation at their borders  to a public network, 
  1735. thus keeping their private addresses private. 
  1736.  
  1737.  If two (or more) organizations follow the address allocation  specified in 
  1738. this document and then later wish to establish IP  connectivity with each 
  1739. other, then there is a risk that address  uniqueness would be violated.  To 
  1740. minimize the risk it is strongly  recommended that an organization using 
  1741. private IP addresses choose  randomly from the reserved pool of private 
  1742. addresses, when allocating  sub-blocks for its internal allocation. 
  1743.  
  1744.  If an enterprise uses the private address space, or a mix of private  and 
  1745. public address spaces, then DNS clients outside of the enterprise  should not 
  1746. see addresses in the private address space used by the  enterprise, since these 
  1747. addresses would be ambiguous.  One way to  ensure this is to run two authority 
  1748. servers for each DNS zone  containing both publically and privately addressed 
  1749. hosts.  One server  would be visible from the public address space and would 
  1750. contain only  the subset of the enterprise's addresses which were reachable 
  1751. using  public addresses.  The other server would be reachable only from the 
  1752. private network and would contain the full set of data, including the  private 
  1753. addresses and whatever public addresses are reachable the  private network.  In 
  1754. order to ensure consistency, both servers should  be configured from the same 
  1755. data of which the publically visible zone  only contains a filtered version. 
  1756. There is certain degree of  additional complexity associated with providing 
  1757. these capabilities. 
  1758.  
  1759.  
  1760. ΓòÉΓòÉΓòÉ 15.7. Security Considerations ΓòÉΓòÉΓòÉ
  1761.  
  1762.  
  1763.  Security issues are not addressed in this memo. 
  1764.  
  1765.  
  1766. ΓòÉΓòÉΓòÉ 15.8. Conclusion ΓòÉΓòÉΓòÉ
  1767.  
  1768.  
  1769.  With the described scheme many large enterprises will need only a  relatively 
  1770. small block of addresses from the globally unique IP  address space. The 
  1771. Internet at large benefits through conservation of  globally unique address 
  1772. space which will effectively lengthen the  lifetime of the IP address space. 
  1773. The enterprises benefit from the  increased flexibility provided by a 
  1774. relatively large private address  space. However, use of private addressing 
  1775. requires that an  organization renumber part or all of its enterprise network, 
  1776. as its  connectivity requirements change over time. 
  1777.  
  1778.  
  1779. ΓòÉΓòÉΓòÉ 15.9. Acknowledgments ΓòÉΓòÉΓòÉ
  1780.  
  1781.  
  1782.  We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-  Werner 
  1783. Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN  Planet), Vince 
  1784. Fuller (BBN Planet), Tony Li (cisco Systems), Anne  Lord (RIPE NCC), Milo Medin 
  1785. (NSI), Marten Terpstra (BayNetworks),  Geza Turchanyi (RIPE NCC), Christophe 
  1786. Wolfhugel (Pasteur Institute),  Andy Linton (connect.com.au), Brian Carpenter 
  1787. (CERN), Randy Bush  (PSG), Erik Fair (Apple Computer), Dave Crocker 
  1788. (Brandenburg  Consulting), Tom Kessler (SGI), Dave Piscitello (Core 
  1789. Competence),  Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie 
  1790. (Internet  Software Consortium) for their review and constructive comments. 
  1791.  
  1792.  
  1793. ΓòÉΓòÉΓòÉ 16. If problems ΓòÉΓòÉΓòÉ
  1794.  
  1795.      The DNS kit nameD server can block if the system is fully "socksified". 
  1796.       Don't hesitate to rename the "socks.cfg" file in the ETC directory when 
  1797.       you are running sockD. 
  1798.  
  1799.      If your configuration is limited to one LAN adapter and one dial adapter, 
  1800.       it is better to test sockd without configuring it... Use the view menu 
  1801.       option to see the config. After tests, check sockd.log ... 
  1802.  
  1803.      If you have really a problem to setup a name server on the gateway 
  1804.       station, define a "hosts" file. For that, when you are testing your 
  1805.       "sockdial.cmd" after the connection and authentication are successfully 
  1806.       completed, use : 
  1807.        host www.yahoo.com 
  1808.       in an OS/2 Window. You are able to get the IP addresses of your favorite 
  1809.       servers. If you install a "completed" hosts file in the ETC directory of 
  1810.       the end-user PC you can test sockd with WebEx (socks V4) without setting 
  1811.       a name server. With a name server and its caching mechanism, you have 
  1812.       access to any server, with the hosts file access is limited... 
  1813.  
  1814.      To support socks V5 DNS, the dial-up connection is started automatically 
  1815.       if the name can NOT be locally traduced... A better solution is perhaps 
  1816.       to define a list of the "internal" domain names, and to start the 
  1817.       connection only if the request is for another domain name. On the time 
  1818.       being, sockd start the dial-up connection for V5, before checking if the 
  1819.       connection is "permitted" except if the DNS name can be locally traduced. 
  1820.       With the current implementation: 
  1821.       - in socks V4 the first session (to start the dial-up connection) MUST be 
  1822.       to a "locally" defined DNS name (then sockd check if the client has 
  1823.       access  to this address before starting the connection). 
  1824.       - in V5 DNS support, the first session can be to any DNS name, but if 
  1825.       this  name can NOT be locally translated, there is a delay (nearly 1 min. 
  1826.       in my tests)  then the dial-up connection is started and the DNS name 
  1827.       translation request  is sent to the "external" name server.  The 
  1828.       "permission" can be checked only after sockd received the destination  IP 
  1829.       address. 
  1830.  
  1831.      In this version , only the flags "811" (<UP,POINTTOPOINT>) or "851" 
  1832.       (<..,RUNNING>) are considered as "good" status (connection established) 
  1833.       on the dial-up adapter. If the "auto-dial" facility doesn't work for you, 
  1834.       please check these flags with: 
  1835.       "ifconfig ppp0" (by sample) 
  1836.       Send a note to me and I'll add the required support... 
  1837.  
  1838.      With current V4 applications like WebEx, the first session must be done 
  1839.       to a DNS name converted locally (named or hosts file). After the dial-up 
  1840.       connection is established, names can be translatted by the Internet 
  1841.       provider name server, and cached in the local nameD. 
  1842.  
  1843.      Using WebEx through sockd, some ".gif" files are not correctly received I 
  1844.       am investigating why and how to improve it. 
  1845.  
  1846.  
  1847.   Any suggestion or question to Philippe Gillain (GILLAIN at BRUVMIS1 or 
  1848.  Philippe_Gillain@be.ibm.com)...