FW: [sclug] Firewalls

[Tom Dawes-Gamble]

lug at assursys.co.uk wrote:
> On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:
> 
> 
>>lug at assursys.co.uk wrote:
>>
>>>On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:
>>>
>>>>Yes,  but NAT sould only change the envelope part of the packet and not the
>>>>contents.
>>>
>>>
>>>That depends. It's impossible to get some protocols (non-PASV FTP being the
>>>most notable) working without modifying the payload. Yes, this is prone to
>>>error - consider what happens to the size of the packet if the client
>>>address is 1.2.3.4 and the NATted address is 111.122.133.144. Now consider
>>>what happens if the payload was already of size (MTU-40)...
>>>
>>
>>That's not a nice exercise to leave to the reader.  :-)
>>Though my guess is
>>
>>MTU - 40 = MTU - Envelope
>>
>>then in the envelope 1.2.3.4 would be 00000001 00000010 00000011 00000100
>>          and 111.122.133.144 would be 01101111 01111010 10000101 10010000
>>
>>in that case the envelope does not change size.
> 
> 
> It would be, apart from the fact that FTP uses ASCII when sending PORT
> commands... suddenly your packet is 4x2=8 bytes longer than it was. But the
> packet was already at maximum MTU size! Yow!
> 

But surely the port "command" is not part of the envelope but is in body.

The Envelope to my mind should be fixed size and contain the source & 
destination IP Addresses, Port number, Protocol (UDP | TCP ), Sequence number 
and maybe the source and destination MAC addresses packet size and so on.
Numbers should be in binary and in a machine indedendent order to allow for
the big endian little endian problems.  ASCII does not make sense in the
Envelope.  After all you may be talking to an EBCIDIC machine.  :-)

Tom.




-- 
There are 10 sorts of people.
Those that understand Binary and those that don't.