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

Joe Touch <> Sat, 01 August 2015 00:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 560B81ACE31; Fri, 31 Jul 2015 17:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPaI4KM_T-zf; Fri, 31 Jul 2015 17:47:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E8931ACE2F; Fri, 31 Jul 2015 17:47:07 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t710kaIk011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 17:46:37 -0700 (PDT)
To: Mark Smith <>
References: <> <> <> <> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 31 Jul 2015 17:46:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t710kaIk011548
X-ISI-4-69-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>, v6ops list <>, Mikael Abrahamsson <>, "Heatley, Nick" <>,
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: Sat, 01 Aug 2015 00:47:08 -0000

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.