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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Joe Touch writes:
> 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.
> 
> > 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.

> Joe
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]