On 26/08/20 7:39 am, Alex Rousskov wrote: > On 8/25/20 3:21 PM, Jonas Steinberg wrote: > >> is this something I could submit as a feature request via github or >> is it too crazy or out-of-scope for the roadmap? > > I am not familiar with draft-ietf-nvo3-geneve details, but I see nothing > particularly crazy on the surface of that draft: Squid is already > capable of tunneling intercepted TLS and forwarded HTTP CONNECT traffic > while GENEVE seems like one more way to tell Squid about the desired > tunnel end points. > First thing that I notice is that GENEVE is UDP/IP based. HTTP CONNECT tunnels that Squid uses are for TCP based traffic. Taking a slightly deeper (but still brief) look through its protocol design I see just another IP based tunnel. There are hundreds of these already. This type of protocol is best handled by a regular router and/or firewall. As Alex said, Squid can be extended. But IMO this is not worth the effort. It would be better to wait on OS networking stacks to support the decapsulation. The OS can pass any relevant traffic to Squid via the regular socket APIs - like how GRE and IP-IP tunnels are supported. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
