To: perot@pallas.amp.uni-hannover.de
Subject: ICMP masquerading (solved)


Hi Peter!

I was thinking on the ICMP problems with masquerading today, and I
decided to read through the ICMP specification again.  Very shortly
I found a diagram which shows that there is no problem whatsoever !

I include this here:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is the basic ICMP message format, which I assume will be preceded
by its own IP header to form a complete datagram.  The key to how it
can be properly masqueraded lies in the lowest text line:

   |      Internet Header + 64 bits of Original Data Datagram      |

This is where we can find the relevant protocol port numbers of the
original datagrams for masquerade translation, and where we also must
encode such information if 'local remotes' need to send ICMP messages
to servers on Internet.  This is in addition to the IP patching needed
in the IP header of the ICMP message itself of course.


This does not cover all of the ICMP message types however.
Six message types use a different format.  These are:

Type	Description
----	-----------
  0	echo reply
  8	echo message
 13	timestamp message
 14	timestamp reply
 15	information request
 16	information reply
 
The format used by these six types begins identically:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code     |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To this is added some additional data for some of the types, but the
'Identifier' shown here is free for use like TCP/UDP port, provided
we set the 'Code' field to zero.  This is entirely up to us, since
none of these message types should ever be sent to us spontaneously.
They will only be used at all, if any of our software wants/needs to.
Note also that for these six message types the RFC gives no other
example of a legal value for 'Code' than zero. 

Since clients have not been allowed to use ICMP before, and since STX
drivers have not existed with STiK 1, it is no problem that the
'Identifier' field is not available for clients/STXs (since we
must use it for masquerading).  If you see that as a problem it can
easily be solved however, by adding a word to the masquerading struct
used in the arrays as I described in my earlier mail on masquerading.
That would be a bit wasteful though since unused for normal traffic.


Thus the entire ICMP problem can be dealt with simply by recognizing
and handling the two format groups described above.  The testing and
branching of the code for TCP and UDP is unaffected by this, so such
implementation will have no effect on their speed, though the speed
of ICMP masquerading will be slower than for the other protocols.
(Since it is a little more complex.)


I thought there had to be a way of doing this, and I'm fairly sure
that this is the way it has to be done.  I realize now that coding
this stuff will have to wait a bit, but at least we now have one
problem less to worry about when the time comes.

Btw:
  Are there any other protocols we need to worry about, which are
  not implemented 'on top' of TCP (thus no worry)...?

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