[Dnsmasq-discuss] Single-port mode for TFTP

[Simon Kelley]

On 31/12/2019 08:36, kvaps wrote:
> On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier <khm at sciops.net
> <mailto:khm at sciops.net>> wrote:
> 
>     If you need this kind of functionality in Kubernetes you're much better
>     off using a different CNI plugin to manage your networking.  There's no
>     inherent NAT requirement imposed by Kubernetes itself.
> 
> 
> This is not about CNI networking, inside cluster tftp is working pretty
> fine.
> This is more about service networking (kube-proxy) and accessing
> services from outside.
> Example: when you need to boot some node, on the early booting stage it
> can't be member of cluster.
> 
> Of course you can use hostNetwork=true, but it is less secure and not
> redundant.
> 
>     That approach is dangerously broken.  The transfer IDs and the ports are
>     supposed to match; ramming everything over a single port is going to   
>     break down when you have a lot of transfers happening simultaneously.
> 
> 
> The packets are always sending to the client specific port. There is no
> put requests.
> What is actually broken? Example tcpdump:
> 
> This is standard mode:
> IP 172.17.0.2.42447 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
> IP 172.17.0.1.56457 > 172.17.0.2.42447: UDP, length 15
> IP 172.17.0.2.42447 > 172.17.0.1.56457: UDP, length 4
> 
> This is single port mode:
> IP 172.17.0.2.56296 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
> IP 172.17.0.1.69 > 172.17.0.2.56296:  15 DATA block 1
> IP 172.17.0.2.56296 > 172.17.0.1.69:  4 ACK block 1
> 
> - kvaps
> 

I think this will work, AS LONG AS the client uses a unique port for
each transfer, which seems likely, since the RFC says it should. Note
that NAT chosing a  unique port ain't enough, the client has to use a
new port for each transfer when it does more that one, to avoid the
possibility of packets getting mixed up. Making the changes to the TFTP
code looks like a bit of a pain, however. It should have a specific
option to enable it, with a big NOT STANDARDS COMPLIANT warning, as you
suggest.

Do you have a patch to try, or do you want me to look at this?


Simon.



> 
> On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier <khm at sciops.net
> <mailto:khm at sciops.net>> wrote:
> 
>     On Mon, Dec 30, 2019 at 12:51:30PM +0100, kvaps wrote:
>     >
>     > Note that Kubernetes uses NAT for external services, so it's not
>     possible
>     > to run TFTP-server for external clients there. There is one proposed
>     > solution for that, it suggests moving away from the RFC and implement
>     > --single-port option for always reply from the same port which was   
>     > requested by the client.
> 
>     That approach is dangerously broken.  The transfer IDs and the ports are
>     supposed to match; ramming everything over a single port is going to   
>     break down when you have a lot of transfers happening simultaneously.
> 
>     If you need this kind of functionality in Kubernetes you're much better
>     off using a different CNI plugin to manage your networking.  There's no
>     inherent NAT requirement imposed by Kubernetes itself.
> 
>     khm
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>