Forum Discussion
svs
Cirrostratus
CirrostratusIncosistent forwarding of HTTP/2 connections with layered virtual
Hi, I'm using a layered virtual configuration: Tier1: Virtual applying SNI-Routing (only SSL persistence profile and LTM policy as described in https://www.devcentral.f5.com/kb/technicalarticles/s...
zamroni777
Nacreous
Nacreoussimply do the ssl temination in tier1 vserver.
the new udp based http/3 uses same coalescing mechanism.
it's faster than tcp based http v1.1/v2.
i don't think it should be avoided as youtube, facebook and many cdn use it.
svsCirrostratus
CirrostratusI agree that we can't ignore that, just because it breaks our beloved concepts and new technologies often require new methods and concepts. That's fine.
However, my main caveat is, that I need to re-encrypt between tier1 and tier2 virtual, if I don't want to create a security gap or provoke legitimate discussions with the guys from information security, by transporting the traffic unencrypted between both virtuals. I'm talking about the usage of tcpdump on the BIG-IP. Yes, I'm aware, that each encryption on the BIG-IP can be dumped and decrypted. But there's a difference from the information security point of view, whether I need to invest some effort to get unencrypted traffic (which could be formally prohibitted) or if my configuration is "open like barn door".
zamroni777are you aware that this will solve the issue? Do you have practical experience with this configuration? The descriptions from F5 require customized (server) SSL profiles to "full-proxy HTTP/2". Why do you think that enabling HTTP/2 on tier2 virtual wont result in the same issue? If the same TCP connection is used, why should TLS be re-negotiated by bringing the termination to the tier1 virtual? This would be required to correctly forward the connection to the correct tier2 virtual via SNI-Routing. It's still the same (outer) TCP connection and probably the same (wildcard) certificate...
- zamroni777
as long as t1 vserver does ssl termination, we can use either http or https between the t1 and t2.
t1 forwards to t2 based on request's http host header. instead of the sni.
t1 can see http host header because t1 terminates client's ssl sessions.i myself is not fan of tiering as we have to buy t1 ltm only for it to forward to another/t2 ltm while the t2 actually can do what the t1 does.
i see bigip as application layer oriented device, not network layer oriented like router etc.
so, put bigip in servers's subnet using private ip nat-ed by upfront router/netfw, run ltm and waf in same vservers and forward to pools accordingly.
regarding ips/ids needs to decrypt ssl to do inspection, i think just let waf like asm does the app layer inspection.
waf can do more than ips/ids while usually also cheaper.
https://www.f5.com/pdf/white-papers/big-ip-asm-ips-differences-wp.pdf- svs
Ok. I see your point. The idea and reason behind the routing between virtuals (t1, t2, t3) has nothing to do with a focus on network or application layer. In fact, I see the BIG-IP as a pure application layer device as well. The reason behind layered virtual is to fulfill different requirements in
- SSL/TLS, i.e.
- one app still requires TLS1.1 and CBC ciphers, while all others not
- one app requires client certificates
- one app needs a server-side SSL profile and others not
- HTTP (i.e. one app needs to re-chunk HTTP requests or one app shall return the HSTS header)
- based on the BIG-IP HUD chain (APM should be secured by WAF, although WAF is processed in HUD chain AFTER APM)
I know that almost all of these reasons can be fixed with iRules, but still the concept is cleaner because iRules have to consider the hostname again and again for a "per app" view.
There are more reasons for this concept. However, of course we try to save IPv4 addresses for our customers as well. Not each organization has as many IPv4 addresses as apps available. 😉
Back to coalesce: From your response it feels like you only expect that this would my problem, right?
- SSL/TLS, i.e.