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

Joe Touch <> Wed, 05 August 2015 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A9821A854D; Wed, 5 Aug 2015 09:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.71
X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EiVs-PTwLqus; Wed, 5 Aug 2015 09:59:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C4FC1A6FE7; Wed, 5 Aug 2015 09:59:19 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t75GvHDp022626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2015 09:57:19 -0700 (PDT)
To: Mark Andrews <>
References: <> <> <> <> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 5 Aug 2015 09:57:17 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: v6ops list <>, "" <>, Mark Smith <>,
Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2015 16:59:21 -0000

On 8/5/2015 1:36 AM, Mark Andrews wrote:
> In message <>;, Joe Touch writes:
>> Hi, Mark,
>> On 7/31/2015 4:45 PM, Mark Smith wrote:
>>> On 31 July 2015 at 23:21, Joe Touch <>; 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.
>>> 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 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.
>>> 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.
>> 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.
> Actually it is to provide a *Trivial* File Transfer Protocol that
> works over UDP.  If it was LAN only it would be LFTP.  TFTP works
> fine over inter-continental links.  Been there, done that.

It *can* work anywhere, but its lack of security and congestion control
are good reasons not to use it outside protected environments.

Further, it was "trivial" back when TCP was thought to be comparatively
huge; reasonable implementations of TCP are very small and memory isn't
anywhere near as limited.