To: perot@pallas.amp.uni-hannover.de
Subject: Re: [4] TCP patch for STiK 2                                                    


On Fri, 21 Feb 1997 12:05:26 Peter Rottengatter <perot wrote: 
>
>
>On Wed, 19 Feb 1997, Ronald Andersson wrote:
>
>> I thought I'd better add a little foreword today, since I have been
>> writing on this letter so long it feels more like having written a novel.
>> Further below in the text you will find a complete model for full IP
>> masquerading which I have constructed today.  This should be useful
>
>Interesting certainly. Let me tell me here that my time right now is 
>limited, so if I run out of it commenting on this letter, you'll find the 
>rest later on the weekend.

Ok, I was a bit limited myself in my first reading of this anyway,
so I guess any follow-up may already be waiting on the server.


>> regardless of how we chose to solve the TCP implementation.
>> It should work fine for both UDP and TCP, but not for 'pure' IP.
>> ICMP appears to be based on 'pure' IP  too, is that a problem...?
>> Do we ever need ICMP over the modem...?
>
>IP-masquerading is in fact not defined for IP, even though the name 
>suggests it. Masquerading maps high level protocol ports, which do not 
>exist on the IP level. ICMP is part of IP, not based on it. From what I 
>know of masquerading, there is no concept of doing it in a way that 
>supports pure IP and ICMP too. It would be nice to have it for ICMP too, 
>as Ping and Traceroute do not work without ICMP, but I guess we can't 
>have it (unless you have a really brilliant and inventive idea how to do 
>it ;-) ).

The RFC's I read seem to say that ICMP is not intended for client traffic
anyway, so it may not be a big problem.  A form of masquerading then seems
possible without needing the protocol 'port' field, since we only have to
reach the correct machine, not the sending client.  I'll have to study the
RFC in closer detail to have a firm opinion on this though.


>> It does not seem so from the RFC, but I still don't know for sure.
>
>Does this mean you studied an RFC on masquerading ? Didn't know one 
>exists, which one is it ?

No, I studied the RFCs on IP, TCP, UDP, and ICMP, (all in parallel) while I
wrote that mail.  Had I found a masquerading RFC I would probably just have
mentioned to you where to find it instead of writing what I did.  Perhaps it
was better this way, because I was forced to learn some things the hard way.


----- snip ----- re: KA9Q port for STiK 2
>
>Just letting you know that I studied the ka9q source code, and started 
>to port it. The structure of the code is bad, but it is rather well 
>commented, so progress isn't too bad. I think within the weekend I'll be 
>able to establish the first TCP connection, without ability to use it, 
>though. Studying the code, I also saw a brilliant solution for a problem 
>I encountered in the IP core, and which I solved rather awkwardly. So 
>I'll apply that soon, and already for that it paid to spent the effort of 
>downloading and studying the ka9q source.

Good!  This sounds promising.


----- snip ----- re: KA9Q API
>
>The API (surprisingly ?) isn't too far from STiK's API. However, I 
>encountered one problem, which is one for UDP too. It is on how to 
>report ICMP error codes to the application. I think I should ask 
>publicly for a decision on this, so see my separate letter to the 
>STiK list.

Ok, I'll look for it then.


>> Also, I know Dan has spoken of TCP and IP being mixed together in STiK,
>> and that is likely true in KA9Q as well then, which will make it more
>> difficult to extract the TCP stuff to a module.  I don't mean to discourage
>> you, just to warn you about things that might make it more demanding.
>
>It's not at all mixed in ka9q. True, if that had been the case, I would 
>not have started to port it.

Excellent.  That could have been a major problem.


>> [ ... lots of masquerading suggestions deleted ... ]
>> 
>> Do you know of any other reserved values ?
>
>No, there aren't. The well-known ports can be treated just like any others.

Good.  I was unsure of this, though it seemed to be so.  Thus we only need a
simple +/- 1 conversion between array indexes and port field values, and even
this can be eliminated if we refrain from using array element zero.  This only
wastes ten bytes to buy free some CPU time which I consider a bargain.
(Martin might disagree, but I think no one else would :-)


>That all gives me a lot to think about, which will need a little time. I 
>see quite a few problems in details, for instance you seem to haven't
>cared about ICMP responses to TCP/UDP datagrams.

That is correct and is due to my lacking knowledge of this subject.  If these
responses refer to failed connections I would expect them to refer to the
source IP and protocol port for identification of them.  It is then those fields
that need translation into local addressing.  To be sure of this it will be
necessary to study the ICMP and TCP RFCs in detail though.


>It might very well be that those can be sorted out. But I really need to think
>it over first.

Yep, me too.


>> Fine, but I now think that the masquerade method I constructed should be
>> evaluated by you too, and if found valid implemented ASAP, because without
>> it we can't send any valid TCP traffic to the internet using this scheme.
>
>Oh, I think a masquerading scheme is certainly required, but I thought so 
>far the time hasn't come yet. I think the package needs a thorough test 
>with TCP first and quite a bit of debugging, before we start on masquerading.

Probably, but with the ST1K approach we would have had no choice, since the
pseudo port we discussed would not own the proper IP.


>> Also, since it is needed with either TCP method, it should have priority.
>
>I won't call it _needed_ at this stage. Still, a whole network of 
>machines can be linked to the Internet, and TCP to connect to Internet 
>can be used too, but just restricted to the machine with the 'proper' IP 
>address.

No.  None of the machines except the 'proper' one may send any packages on
any protocol to Internet, since their IP headers contain illegal IP numbers.
Without masquerading those packages reach the ISP in illegal form regardless
of the protocol.  I'm not sure how/if the ISP will respond to that, but it
certainly won't work as intended.


> Since by far the most of us have only machine connected to their 
>ISP anyway right now, this is not at all a restriction.

True in a way.  A main goal is naturally to reach the point where STiK 2 can
replace STiK 1 for client usage, which only needs single-port use.


>It will become one if the multi-port capability is to be _fully_ exploited.

Yep, so perhaps I was a bit over-eager, but then it is an exciting subject.


>This certainly will not be the case before

>a) TCP is finished

	And you are now working on it.


>b) the RESOLVER is finished 

	This should have been Martins job, but I am beginning to doubt his
	intention of ever delivering it.  At least not until we let him
	dictate a brand new interface etc.  (ie: when hell freezes over)


>c) PPP is finished

	I know you're already working on this too.


>d) the Dialer is finished.

	Another of your projects in progress.


>Put in another way : Before it can be _released_ as a STiK 1 replacement.

I assume you mean beta release here though.


The above summary shows clearly that if I am to be any real help at this stage
there is no choice about what to do.  The resolver is needed and you have lots
of other things on your hands already.  Can you tell me where to find source
of existing implementations (those C libs you mentioned for other stacks),
and/or possibly some RFC on recommended usage ?  Then I could at least look the
job over with a view to tackling it.


>Note that no network package for Ataris, not even MiNTnet, is capable of
>masquerading. The possibility of STiK 2 being the first is exciting, but
>we must not neglect more important things that must be done first.

That is correct of course, and going for the proper TCP STX we can do things
in this order.  I do not see how we could have with the ST1K approach though.
That would have required two ports with the same IP number in the system,
which would not have been a very good idea I think.

As for being 'first', I am afraid we'll have to settle for being the first
to do it under TOS, since Linux does have masquerading (being a unix clone).
(Hmmm, I wonder if their sources would be useful for us (if possible to find)).

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
