Received: (from uucp@localhost)
	by maskin.oden.se (8.8.7/8.8.8) id AAA23733
	for <dlanor@oden.se>; Fri, 18 Sep 1998 00:26:57 +0200 (MET DST)
Received: from UNKNOWN(194.25.93.130), claiming to be "on.on-luebeck.de"
 via SMTP by maskin, id smtpdAAAa005mi; Thu Sep 17 22:26:48 1998
Received: (from majordomo@localhost)
	by on.on-luebeck.de (8.8.7/8.8.7) id AAA23115
	for stik-outgoing; Fri, 18 Sep 1998 00:26:53 +0200
Message-Id: <199809172225.AAA23644@maskin.oden.se>
Date: Fri, 18 Sep 1998 00:25:42 +0200 (MET DST)
From: Ronald Andersson <dlanor@oden.se>
X-Mailer: Infitra 0.13b
To: Lonny Pursell <stik@on-luebeck.de>
Subject: Re: STIK: Re: ICQ package for STiK / STinG
Sender: stik@on-luebeck.de
Precedence: bulk
Reply-To: stik@on-luebeck.de
X-UIDL: 0b956ae5ebf7826da4f8a88a3218fe26

On Wed, 16 Sep 1998, Lonny Pursell wrote:
>There is some aditional ICQ info at this location.
>
>http://www.rootshell.com/

Thanks Lonny, I've added this to the other list for my browsing.

Btw:
I've been thinking about a way to solve the problem with DCC stuff in aIRC,
such that it can work for all STinG machines in a LAN, connected through
Masquerade to the Internet.  This will have to be limited to STinG machines
though, because there is no way for me to force a PC (for example) in the
same LAN to use the same method, though it too will be masked.

I do hope that you will stick with me this time, even if I do have to get
a little 'longwinded' about it.  All others are naturally also invited to
give their views on my idea, and suggestions for improvements.

The idea is that some new features be added to the Masquerade module, which
aIRC or other clients/servers with similar needs can use fairly easily to
find IP and port numbers that external DCC implementations can reach them on.
These IP and port numbers can thus be used in local DCC info we send them,
in a way that should make DCC functional on all STinG systems in the LAN.
(They all must run Masquerade, but with port active on at most one of them.)

Naturally these methods should not be used for purely local DCC transfers,
since such transfers do not pass the Masquerade interface to Internet.
I leave it entirely up to clients to determine that for themselves, since
this is outside of the scope of possible tasks for Masquerade.  One way
they can easily use is to check IP's against a list of known local hosts,
and apply the new methods described in this mail only to all other hosts.


1:  The masquerade module should create two new STinG environment variables,
    using setvstr, so that any client can request their value with getvstr.
    These two variables would be defined as follows.  (Brace yourself ;-)


  1.1: MASKED_REAL_IP variable
       The value of this will be the dotted IP string of the IP address
       which is currently being masked by the machine which currently has
       had the Masquerade port activated (by dialer normally).  It will
       thus be the true IP address assigned to the system by the ISP.
       (or possibly your static IP if you have one)  It is important to
       realize that you should not use this value for any other purpose
       than when you need to tell external clients/servers/people about
       the DCC address of our system on the Internet.  It should never
       be used either as destination or source in any TCP/IP packets
       locally.  Masquerade will put it in as needed automatically.

       This variable will be "0.0.0.0" before and after all Masquerade
       sessions, so that value means Masquerade is not currently active.
       You may need to retest this in 'longlifed' client sessions.
       I do recommend it to be done for each DCC command.

       If this variable is absent, then you may assume that Masquerade
       is not installed, and that will remain true throughout that
       session, because the string will be created with "0.0.0.0"
       value as soon as the Masquerade module is booted.  Then you can
       (and should) fall back on current STiK-compatible scheme.


  1.2: MASKED_PORT_BASE variable
       The value of this will be a decimal string for an unsigned int16
       port base number.  This will be used as an offset between local
       port numbers that you should use locally, and the ones that you
       can tell external clients/servers/people that they can reach you
       on.  They will be assigned in blocks of 4K per masked IP, and for
       the machine where Masquerade is active (connected to ISP), the
       base value will be zero, so that there is no offset at all.  That
       means that this machine (only) can be reached by 'wellknown' port
       numbers from external machines.  All other machines will get a
       base value in the range 4K and up to 56K, allowing a total of 14
       machines (local IPs rather) to have individual port ranges, with
       additional machines allowed, but those sharing the final range of
       port numbers (56K to 60K).  Range 60K to 64K will be unused.

       Machines that do not have an individual range will have a variable
       value string "NODCC" to allow recognition of this state, and when
       Masquerading is not active, the string will be set to "00000" on
       all machines, since any port then has to be purely local.  This
       string will always use 5 characters, to avoid any reallocation
       changes in setvstr (depends on STinG optimization).
       
       The above means that with masquerading active the 'modem machine'
       can use all ports in range 0-4095, and these port numbers will be
       identical on the outside of Masquerade, and should be used for
       all DCC info sent to Internet. (with MASKED_REAL_IP of course)

       The non-modem machines are divided into two classes, the most
       important being that of the first 13 local IP's to attempt sending
       packets through masquerade after dialup. Naturally no known LAN
       as yet has had so many STinG systems active, let alone more...
       This class can use all ports in range 0-4095 locally, but these
       will be translated for use on Internet by adding the base value
       to the local port value.  It is the so translated value that you
       should use as DCC info sent to Internet (with MASKED_REAL_IP).

       The final class is not limited in the number of machines, and
       represents those local IPs that had their first packet contact
       with a dialup connection after the first 14 port bases were
       assigned as described above.  These will all have their local
       IPs translated into the range 56K to 60K, but without any real
       correspondence in the translated and local values, so these
       machines can not use DCC or similar services.

       This spec states that the machines which have individual port
       groups should use only local ports 0-4095, and if that range
       is exceeded then masquerading for this port will be done as
       for the class of machines that have no individual port groups.
       This too will work, but not for DCC of course.


2:  In order to make sure that the Masquerade STX running on each machine
    in the LAN has the info needed to update the local string variables
    MASKED_REAL_IP and MASKED_PORT_BASE correctly, the Masquerade STX
    which was activated (by dialer normally) will also function as a
    special server.  Whenever a packet is received from a local IP, which
    is the first packet sent by that IP and destined for the outside of
    the Masquerade filter, then Masquerade will attempt to assign it a
    port group as described in 1.2 above, and will send a packet holding
    the appropriate strings to the machine, addressed to a reserved port.
    All copies of Masquerade will listen to that port as special servers,
    and respond to incoming packets only as follows:

    2.1 They immediately reopen a new listening connection.
    2.2 They extract the strings from incoming data on the old connection.
    2.3 They close the old connection.  (a new one is already waiting)
    2.4 They update the variable strings using 'setvstr(...)'

    Thus all machines in the LAN which have Masquerade installed will get
    their info updated from the 'modem machine' which is a must for DCC.


Ok, that was the idea, complete in outline if not in detail.  I think that
this will solve all the problems with DCC and similar usages, but only if
client authors agree to use it. But I also think that I have made such use
as easy as is possible here, so if this is still not acceptable, then we
may just as well forget it. With masquerading, this is as good as it gets.

I see no further way to simplify methods for the client.  Naturally this
may be due to limited vision, so I am open to any suggestions and ideas
for further improvement.

As I have said long before in mentioning my ideas on this subject, such
a change is a rather significant extension of the current module, and I
do not want to waste such an effort.  I will only do it if I have some
kind of commitment from a client author (like you Lonny) that the stuff
will actually be used.
-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------


