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


On Wed, 26 Feb 1997 08:57:20 Peter Rottengatter <perot wrote: 
>
>On Tue, 25 Feb 1997, Ronald Andersson wrote:
>
>> This does not cover all of the ICMP message types however.
>
>And this is the problem ;-)

Yes, but as I read the ICMP RFC it seemed possible to solve.


----- snip ----- re: the six deviant ICMP message types
>>  
>> 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
>
>This is wrong, unfortunately. the identifier serves some usefule purpose 

According to the ICMP RFC it serves the purpose of letting the originating
server differentiate between simultaneous ICMP responses to various requests.
This is precisely what we need in masquerading.


>(why should it be connected to the code field being zero ???).

Because that is what the RFC says:

----- RFC quote start -----

   Identifier

      If code = 0, an identifier to aid in matching echos and replies,
      may be zero.

----- RFC quote end -----

Note that absolutely none of the examples in the RFC suggest any other legal
value of the code field for any of the six message types involved. 


>For instance when Pinging a host, each subsequent echo request must have a 
>different identifier.

I have not read any RFC on 'pinging', but I assume that this would be to allow
multiple requests to be sent before getting any responses.  The different
identifiers would then be used similarly to TCP/UDP port values, in keeping
the responses distinct.  Thus we could treat them identically for masquerade.

The RFC even suggests that a TCP/UDP protocol port value be used for 'identifier'
which exactly corresponds to the needs we have in masquerading.

----- RFC quote start -----

      The identifier and sequence number may be used by the echo sender
      to aid in matching the replies with the requests.  For example,
      the identifier might be used like a port in TCP or UDP to identify
      a session, and the sequence number might be incremented on each
      request sent.  The destination returns these same values in the
      reply.

----- RFC quote end -----


>> 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.
>
>This might be a possibility, but misusing the identifier is out of 
>question. No net tool would work across machines running a STiK using 
>this sort of masquerading.

I do not see why or how this would be a misuse.  The RFC clearly states
that the 'Identifier' may be used as freely, and for the same purposes,
as the protocol port values of TCP and UDP.  I do not see why the net
tools should have any problem with this form of masquerading.


>> Btw:
>>   Are there any other protocols we need to worry about, which are
>>   not implemented 'on top' of TCP (thus no worry)...?
>
>There are quite a few, but seldomly used. Dunno if they'll ever get 
>implemented. There is a real-time data protocol (RDP) for instance, that 
>could be used for Internet phone.

It would be best to check them out anyway, just to get a general idea
of possible compatibility problems.  I guess I'll do that by and by.


Summing up:

Since you and I have reached such divergent opinions on the legality of
masquerading ICMP the way I suggested, perhaps we use different RFCs.
I therefore include the header of my ICMP RFC below.

----- RFC header start -----
Network Working Group                                          J. Postel
Request for Comments:  792                                           ISI
                                                          September 1981
Updates:  RFCs 777, 760
Updates:  IENs 109, 128
----- RFC header end -----

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