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

[Mark Smith <[e-mail]>]

Hi Joe,

On 1 August 2015 at 10:46, Joe Touch <[e-mail]> wrote:
> Hi, Mark,
>
> On 7/31/2015 4:45 PM, Mark Smith wrote:
>> On 31 July 2015 at 23:21, Joe Touch <[e-mail]> wrote:
>>> TFTP servers are typically reached at UDP port 69.
>>>
>>> It does not use ports or addresses in-band and thus should not need an ALG.
>>
>> Hmm, to my mind, an "ALG" is necessary if something about the protocol
>> needs to be understood e.g., look for/change in-band ports or
>> addresses, and possibly set up corresponding state or temporary access
>> list/firewall permissions for related traffic.
>>
>> In the case of TFTP, it is the "TID"s:
>>
>> "The transfer identifiers (TID's) used by
>>    TFTP are passed to the Datagram layer to be used as ports; therefore
>>    they must be between 0 and 65,535.  The initialization of TID's is
>>    discussed in the section on initial connection protocol."
>>
>> " A
>>    requesting host chooses its source TID as described above, and sends
>>    its initial request to the known TID 69 decimal (105 octal) on the
>>    serving host.  The response to the request, under normal operation,
>>    uses a TID chosen by the server as its source TID and the TID chosen
>>    for the previous message by the requestor as its destination TID.
>>    The two chosen TID's are then used for the remainder of the transfer."
>
> Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair.
> It works a bit like FTP in that it "hands off" the transfer to the
> server port indicated by the server-side TID after the initial request.
>

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.

>> 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.
>
> It never will. The first packet is supposed to have a destination TID of
> 69 but the rest of the session uses TIDs chosen by each end.
>
>         client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69
>
>         server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X,
>         which is where the rest of the transfer stays until a new TID
>         is selected.
>

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.
However, I missed the bit in the RFC about both ends randomly choosing
the TID when I skimmed through it earlier.

>> I still remember it today
>> because I was only able to get around the unpredictable TID selection
>> on both ends by using just host IP addresses, which had some risks
>> because it was a very coarse way of selecting "interesting"
>> dial-on-demand traffic to hold the link up.
>
> I'm not sure what you were doing; "using just host IP addresses" doesn't
> fix the issue because TFTP still wants to pick TIDs, and the UDP ports
> vary when the TIDs do.
>

The issue was that only certain types of traffic were both allowed to
trigger a dial on the dial-on-demand link and to hold it up. Matching
on UDP port 69 would bring up the link at the start of the TFTP
transfer, however the subsequent TFTP traffic wouldn't match on UDP
port 69 of course, so the d-on-d link would be torn down fairly
quickly (we had low value tear down timers to reduce cost and
contention for dial (ISDN) ports). So the only way I could "identify"
the TFTP traffic to keep the call up was to go down a layer, and match
on the IP addresses of the known sources/destinations of the TFTP
transfer. Of course, that isn't really selective at all, so any
traffic to or from those TFTP source/dest addresses would bring
up/hold up the d-on-d link. Fortunately the TFTP clients were routers,
so traffic directly to them was more controlled and limited than if
they had been general purpose hosts.

>> 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.

1:1 IPv4 to IPv6 addressing for an Anima network may not be possible
to require however, so an ALG for TFTP might be unavoidable.

> 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!

Regards,
Mark.