Re: [BEHAVE] [v6ops] protocols without need for ALG ?

[Joe Touch <[e-mail]>]

Hi, Mark,

On 7/31/2015 7:50 PM, Mark Smith wrote:
...
> If I recall correctly, FTP uses TCP port 20 on one of the ends of the
> file transfer, so that's the fixed port you can match on if you need
> to.

FTP has two modes. Active mode uses a fixed server port (21) for
commands and a fixed client port (20) for each data transfer.

Passive mode uses a fixed server port (21) and let's the server tell the
client the server's port for each subsequent transfer. Passive mode
won't work when the client is behind a NAT because the server can't call
the client on a known port.

In passive mode, the ports are sent back from the server in-band. It
works when the client is on the private side of a NAT because the client
still calls the server.

In-band port numbers are used only in passive mode. You'd think that
would mean that passive mode would require translation, but it's because
of the direction of the use of the ports that translation isn't required.

>>> I think a server could choose to continue to use 69 as its TID for the
>>> full transfer, however in my case it didn't.
...
> I haven't thought much about it, however I was thinking that the
> combination of client address and TID would uniquely identify the file
> transfer, so the server could still use TID 69 if it chose to.

Yes, it *could*, and that'd be a decision totally up to the server.
However, the server code would need to know when it can 'reuse' that
number. By the current spec, the TIDs are not reused (for some time
period) regardless of address, which simplifies servers state.

Note that there might be another reason for this. Booting might occur
from a temporary address or even a shared address, so there might be a
benefit to not needing to avoid reuse of that one port to that one address.

...
>>> So if in Toerless's scenario it is stateless 1:1 translation between
>>> IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP.
>>> However, if the translation is stateful because translation between
>>> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a
>>> mapping of some form.
>>
>> So first let me backtrack - TFTP requires an ALG to work through a NAT
>> even when the client is on the private side. The return traffic content
>> needs to be inspected to be able to update the private:public
>> translation entry.
>>
>> I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an
>> ALG. I can't imagine how to make sense of it safely in a non-1:1 case.
>>
> 
> I was thinking that stateless 1:1 translation between IPv4 and IPv6
> addresses in the IP headers would work without an TFTP ALG, as long as
> the UDP Ports/TIDs could be ignored, as there are no IP addresses in
> the TFTP packets that would need to be translated.

I really don't think you want to run TFTP through anything that isn't
local (see below).

...
>> Note that the whole point of TFTP is to be used on a LAN only. It has
>> zero security, and it's easily possible that the translation entry could
>> inadvertently affect some other UDP translation entry.
> 
> For many years it was the only way to upload firmware and
> configuration into a certain vendor's routers, and usually they were
> remote!

People used to leave their front doors unlocked too, but those days are
over. IMO, TFTP ought to be blocked through anything that indicates
"off-lan" access.

(even though TFTP is still widely used, e.g., in UEFI)

Joe